Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Sécuriser la connexion Bluetooth Low Energy de son objet connecté

83124b745752d1a1b0ca2eee1af0bd48?s=47 Alexis DUQUE
December 07, 2018

Sécuriser la connexion Bluetooth Low Energy de son objet connecté

83124b745752d1a1b0ca2eee1af0bd48?s=128

Alexis DUQUE

December 07, 2018
Tweet

Transcript

  1. #DevoxxFR #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Sécuriser son Object Connecté Bluetooth LE

    Alexis DUQUE @alexis0duque
  2. #embeddedSEC18 #BleSecurityConf About Me ALEXIS DUQUE R&D and Security leader

    at Rtone PhD @alexis0duque #BleSecurityConf alexisduque alexisd@rtone.fr security.rtone.fr | sli.do/BleSecurityConf medium.com/rtone-iot-security EXPERTS IN SMART AND CONNECTED THINGS #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf
  3. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Internet Of Things Security

  4. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf “20 billions interconnected devices by the year

    2020” Gartner
  5. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf “8.4 billions Bluetooth Low Energy devices by

    2020” Bluetooth SIG
  6. #embeddedSEC18 #BleSecurityConf IoT Security Challenges • Uncontrolled Environment • Heterogeneity

    • Users and Manufacturers not aware of security risks • Scalability • Constrained Resources • Surface of attacks: hardware + software
  7. #embeddedSEC18 #BleSecurityConf Attack Surface Area

  8. #embeddedSEC18 #BleSecurityConf IoT Privacy Challenges • How to obtain informed

    consent? • How can people have control over data? • Who is responsible? • How data can be safeguarded? • How do you detect attacks or leaks?
  9. None
  10. None
  11. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Bluetooth Low Energy

  12. #embeddedSEC18 #BleSecurityConf Bluetooth LE Bluetooth Low Energy = BLE =

    Bluetooth 4/5 = Bluetooth SMART Completely different than previous Bluetooth 2, 3 (BR/EDR) Designed for low energy usage, simplicity rather than throughput
  13. #embeddedSEC18 #BleSecurityConf Bluetooth LE Bluetooth 4.0 has weak security mechanisms

    Bluetooth 4.2 adds strong encryption Bluetooth 5 increase throughput and range
  14. #embeddedSEC18 #BleSecurityConf Bluetooth LE 3 devices roles: Central / Advertiser

    / Peripheral
  15. #embeddedSEC18 #BleSecurityConf Bluetooth LE Client Write Request Server Confirmation Client

    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
  16. #embeddedSEC18 #BleSecurityConf BLE Security & Pairing What are we protecting

    against ? • Man In The Middle Attacks • Passive Eavesdropping • Tracking: Broadcasting Identity Information (E.g. Mac Address)
  17. #embeddedSEC18 #BleSecurityConf BLE Security & Pairing Phase 1: Pairing Feature

    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
  18. #embeddedSEC18 #BleSecurityConf Bluetooth Legacy Pairing Phase 2: Authentication and Encryption

    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
  19. #embeddedSEC18 #BleSecurityConf Bluetooth 4.2 Pairing Phase 2: Authentication and Encryption

    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
  20. #embeddedSEC18 #BleSecurityConf BLE Security & Pairing Phase 3: Transport Specific

    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
  21. #embeddedSEC18 #BleSecurityConf BLE Privacy Feature Reduces the ability to trace

    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
  22. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Bluetooth Core Specification “None of the pairing

    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!!
  23. #embeddedSEC18 #BleSecurityConf Bluetooth 4.2 Encryption Elliptic Curve Diffie Hellman P-256

    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
  24. #embeddedSEC18 #BleSecurityConf Bluetooth Vulnerabilities Lake of BLE Authentication and/or Encryption

    Hardcoded secrets, default credentials, encryption keys Unsafe Software Implementation Unsafe BLE Driver Implementation Unsafe Protocole Design
  25. #embeddedSEC18 #BleSecurityConf BlueBorne Vulnerabilities Bluetooth Driver Implementation https://www.armis.com/blueborne/ Android, Windows,

    iOS & Linux Amazon Echo and Google Home 8 vulnerabilities
  26. #embeddedSEC18 #BleSecurityConf BlueBorne Vulnerabilities Heap-based Buffer Overflow Integer Underflow Memory

    Corruption + Privilege Escalation + Remote Code Execution Payload Injection + Remote Code Execution “Heartbleed Like” Data Leak Fake Ip Interface + Packets Interception
  27. #embeddedSEC18 #BleSecurityConf BleedingBit Vulnerability Exposes Enterprise Access Points and Unmanaged

    Devices to Undetectable Chip Level Attack TI CC2540 Driver Implementation https://www.armis.com/bleedingbit/ Cisco, Aruba, Meraki router Any CC264x,CC2650,254x CC1350 devices 2 vulnerabilities
  28. #embeddedSEC18 #BleSecurityConf BleedingBit Vulnerability • Remote Code Execution (CVE-201816986) Aruba

    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
  29. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Hacking Unsafe BLE is Easy! BLE USB

    dongle (CSR8510) Ubertooth nRF or TI Sniffer Wireshark
  30. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Many of the vulnerabilities discovered are 10

    years old!
  31. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Bluetooth LE Security with nRF52840

  32. #embeddedSEC18 #BleSecurityConf nRF52840 « High-end nRF52 multiprotocol SoC for high-performance,

    feature-rich applications with best-in-class security ». 64 MHz Cortex-M4F 1 MB Flash, 256 KB RAM 2.4 GHz Transceiver, NFC-A Bluetooth 5, Bluetooth mesh ANT, 802.15.4, Thread, Zigbee Security Feature: ARM TrustZone® CryptoCell.
  33. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf LE SECURE CONNECTION WITH NUMERIC COMPARISON •

    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
  34. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf LE SECURE CONNECTION WITH NUMERIC COMPARISON attr_perm_t

    perm[MAX_CHARACTERISTIC]; prop_attr_t prop[MAX_CHARACTERISTIC]; perm[0].perm_read = BLE_GAP_CONN_SEC_MODE_SET_LESC_ENC_WITH_MITM; perm[0].perm_write = BLE_GAP_CONN_SEC_MODE_SET_LESC_ENC_WITH_MITM; prop[0].read = 1; prop[0].write = 1; prop[0].notify = 1; STEP 2: Configure GATT Characteristics Attributes
  35. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf LE SECURE CONNECTION WITH NUMERIC COMPARISON •

    Init ARM CryptoCell Peripheral nrf_crypto_init(); • Call lescGenerateKeyPair() to generate the ECDH keys. lescGenerateKeyPair() STEP 3: Generate Cryptographic Keys for ECDH Protocol
  36. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf LE SECURE CONNECTION WITH NUMERIC COMPARISON if

    (accept) { key_type = BLE_GAP_AUTH_KEY_TYPE_PASSKEY; } else { key_type = BLE_GAP_AUTH_KEY_TYPE_NONE; } err_code = sd_ble_gap_auth_key_reply(conn_handle, key_type, NULL); STEP 4: Handle Numeric Comparison request
  37. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf LE SECURE CONNECTION WITH NUMERIC COMPARISON •

    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!
  38. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf LE SECURE CONNECTION WITH NUMERIC COMPARISON •

    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
  39. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Conclusion

  40. #embeddedSEC18 #BleSecurityConf IoT Security Best Practises Security objectives must be

    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
  41. #embeddedSEC18 #BleSecurityConf Firmware Update • Need to be able to

    update firmware • Automatic updates? • Needs to be tested on all hardware variants • Download path needs to be secure • Update path needs to be secure
  42. #embeddedSEC18 #BleSecurityConf sli.do/BleSecurityConf Merci / Thanks you security.rtone.fr #BleSecurityConf |

    sli.do/BleSecurityConf