Bluetooth 4/5 = Bluetooth SMART Completely different than previous Bluetooth 2, 3 (BR/EDR) Designed for low energy usage, simplicity rather than throughput
Write Command Server Server Client Write Command Server Write Client Indication Server Confirmation Client Client Indication Server Confirmation Client Notification Server Notification - Indication Valeur Client Read Request Server Read
Exchange How to determine the Temporary Key (TK)? PHASE 1 PHASE 2 PHASE 3 Just Works: It’s actually a key of zero. No I/O needed Passkey Display: 6-digit PIN, when the device has a display Numeric Comparison: LE Secure Connection only (4.2) Out of band (OOB): e.g. using NFC, VLC, kiwink.io
w/ LEGACY PAIRING • The Temporary Key (TK) is generated using Passkey Entry, OOB, or Just Works pairing methods • TK is authenticated in Passkey Entry & OOB (strength of authentication depends on method used for OOB transfer) • TK is used to generate Short Term Key which will be used to encrypt Phase 3 & subsequent connection PHASE 1 PHASE 2 PHASE 3
w/ LE Secure Connection • Elliptic Curve Diffie Hellman Public Key is transmitted & Diffie Hellman Key is generated • Numeric Comparison, Passkey Entry, OOB methods are used to authenticate confirmation values. Just Works uses Numeric Comparison but is unauthenticated with no MITM protection • LTK computed from Diffie Hellman Key & authenticated values PHASE 1 PHASE 2 PHASE 3
Key Distribution and Encryption Uses Diffie-Hellman Key Distribution to share various keys Encrypt the link using a LTK (LE Sec.) or STK (Legacy Encryption) w/ AES-128 CCM (Counter with CBC-MAC) • Identity Resolving Key is used for privacy (IRK), Signing RK • Long Term Key (LTK) exchanged over the air (Legacy Encryption only) PHASE 1 PHASE 2 PHASE 3
a device over a period of time Use the “resolved” address using the Identity Resolving Key (IRK) IEEE Public Random Private Non Resolvable Random Private Resolvable Random Static
methods provide protection against a passive eavesdropper” • TK is used as the key to generate the STK which encrypts the connection • TK is subject to Passive Eavesdropping because it is either 0 or weak entropy (Passkey Entry) • LTK is transmitted over-the-air in Phase 3 PW NED!!
Public/Private Key Exchange (FIPS approved) AES-CMAC authentication is used during Phase 2 to authenticate values used to derive Long Term Key and protect against MITM attacks LTK is derived and never sent over the encrypted link In practice, ~80% of tested devices do not implement BLE-layer encryption
Overflow Advertising Backet • Over the Air firmware Download RCE (CVE-2018-708) Hardcoded password • BLE chip exploit to compromise the main OS => access to the WiFi network • Solution: update TI BLE-STACK – Disable Unauthenticated OAD
Call pm_init() for initializing the Peer Manager pm_init() • Set the security parameters to be used for all security procedures sec_param.bond = SEC_PARAM_BOND; // 1 sec_param.mitm = SEC_PARAM_MITM; // 1 sec_param.lesc = SEC_PARAM_LESC; // 1 sec_param.keypress = SEC_PARAM_KEYPRESS; // 0 Sec_param.io_caps = BLE_GAP_IO_CAPS_DISPLAY_YESNO pm_sec_params_set() • Subscribe to the Peer Manager events by calling pm_register(). pm_register(). STEP 1: Configure the BLE Peer Manger
In Peer Manager handler, disconnect when the connection could not be secured pm_handler_disconnect_on_sec_failure(pm_evt_t const *p_pm_evt) • In BLE Event Manager handler, start security process pm_handler_secure_on_connection(ble_evt_t const *p_ble_evt) STEP 5: Do not miss that!
Handle the BLE_GAP_EVENT: SEC_PARAMS_REQUEST,AUTH_KEY_REQUEST,PASSKEY_DISPLAY, LESC_DHKEY_REQUEST, AUTH_STATUS • Initiate and send pairing request at the connection • Reject services and characteristics discovery before bonding process ends Some Tips
considered during the product life cycle! • Security “by design” • Risks analysis • Technologies choices and their threat • Architecture requirements for security • Integration in the project workflow • Security review during the project Sec