Security Report: Pre-release validation of Bluetooth MESH CVEs #114
Description
Investigate the following historic CVEs before releasing the first production (non Beta) version of Herald Bluetooth MESH beacon applications.
Sources:-
- [1] NHS Mesh CVEs - https://digital.nhs.uk/cyber-alerts/2021/cc-3870
- Links eventually to: [2] CERT https://www.kb.cert.org/vuls/id/799380
- [3] CERT: https://www.kb.cert.org/
CVEs:-
- [1][2] CVE-2020-26555 - Impersonation in the BR/EDR pin-pairing protocol
- Impact: An attacker could complete pairing with a known link key, encrypt communications with the other device, and access any profiles permitted by a paired device supporting Legacy Pairing
- Initial assessment: Not affected - we explicitly disable BR/EDR in all advertising modes and in the KConfig file
- [1][2] CVE-2020-26556 - Malleable commitment in Bluetooth Mesh Profile provisioning
- Impact: An attacker could obtain a NetKey, decrypting and authenticating up to the network layer, allowing the relay of messages
- Initial assessment: Will not be vulnerable, as per AuthValue (CVE-2020-26557) below.
- [1][2] CVE-2020-26557 - Predictable AuthValue in Bluetooth Mesh Profile provisioning leads to MitM
- Impact: An attacker could brute force the AuthValue and authenticate to both targeted devices, permitting a MitM attack
- Initial assessment: Will not be vulnerable. We intend to use the CryptoCell 310 in the nRF52840 for cryptographic functions and entropy generation. We also plan to use NFC for out of band key exchange. We note the recommendation to rotate AuthValue after each provisioned device.
- [1][2] CVE-2020-26558 - Impersonation in the Passkey entry protocol
- Impact: An attacker could authenticate to the responder and act a as a legitimate encrypted device.
- Initial assessment: Not affected. We explicitly do not allow LE pairing. We disable BR/EDR. We do use LE connections to communicate with LE Herald devices but that's done over pairing-less LE connections. (This is not used for sensitive data in our MESH use cases. E.g. it just contains public beacon payload information, which we want to be public).
- [1][2] CVE-2020-26559 - Bluetooth Mesh Profile AuthValue leak
- Impact: An attacker could compute the AuthValue and authenticate to the targeted devices.
- Initial assessment: Will not be vulnerable, as per AuthValue (CVE-2020-26557) above.
- [1][2] CVE-2020-26560 - Impersonation attack in Bluetooth Mesh Profile provisioning
- Impact: An attacker could successfully authenticate without AuthValue and perform any operation permitted to a node on that subnet.
- Initial assessment: Will not be vulnerable. We intend to use an additional Out of Band mechanism during provisioning via NFC.
- [3] CVE-2018-5383 Bluetooth implementations may not sufficiently validate elliptic curve parameters during Diffie-Hellman key exchange
- Impact: An unauthenticated, remote attacker within range may be able to utilize a man-in-the-middle network position to determine the cryptographic keys used by the device. The attacker can then intercept and decrypt and/or forge and inject device messages.
- Initial assessment: Herald MESH and LE do not use pairing and it is explicitly disabled in Kconfig. The Herald Secure Payload exchange mechanism in the Herald Protocol V2 currently under consideration will use a Diffie-Hellman method, so we shall use this as reference in our design work. See Add Herald v2 protocol support #82 to track that effort.
BLOCKED Until #113 and #82 are completed. (As we can't close this issue off until the functionality is fully implemented as there may be more CVEs in the meantime).