This blog is the example of how to use the ECDH (Elliptic Curve key generation and Diffie-Hellmen secure key exchange) and AES128 for data protection on the BLE connection instead of bonding/pairing.
This concept is referred to as Bluetooth 4.2 (LE Secure Connection). Secure connections prevent the key from being discovered by a hacker.
More information of the LE Secure connection can be found at below.
What encryption protects against and how?
- We do not want an eavesdropper (Eve) to be able to access our data.
- Encryption protects transmitted data
- To access the data, it needs to be unencrypted with an encryption key
- Pairing is used to create and exchange an encryption key that only Bob and Alice know
- We do not want a Man In The Middle (MITM – Mallory) to intercept our data and read it or make changes to it before Bob gets it
- Mallory needs to fool Alice and Bob into thinking they are talking to each other, but they are both talking to Mallory Alice and Bob are not paired together
- Authentication allo1ws Bob and Alice to check if there is a MITM before they exchange keys
Alice and Bob aim to exchange information using a public key cryptosystem.
- They publicly choose a cyclic group G and a generator x of G.
- Alice and Bob choose private keys a and b respectively, where a and b are random integers.
- Alice computes xa , Bob computes xb and they exchange these values over an insecure network.
- On receiving the information from each other, both Alice and Bob compute the a value xab using their private keys and the fact that xab = (xa ) b = (xb ) .
Now, both Alice and Bob share a secret, namely, the value xab. That is, Alice and Bob have exchanged a key, xab, that can now be used in a conventional cryptosystem to encrypt any messages between Alice and Bob.
By using both private key and public key, the shared secret key would be generated. And then it would use for the AES128 for symmetric encryption.
AES128 Encryption / Decryption
I did the example on the nRF51 with SDK 12.3. You can find such example code at https://github.com/jimmywong2003/SES-Project-For-NRF51 . Example SES project is ble_app_uart_bas_ecdh_aes128.
Welcome to provide any comments. If this blog is useful for you, please give a “Like” for appreciation.
I’m glad to see your tutorial about crypto method for nrf52.
Have you ever used ECDSA to sign a signature for nrf52?
I have no idea about the presentation of “raw public key” and “public key” .
The example code (crypto/ecdsa) uses raw key and change it to internal presentation by ” nrf_crypto_ecc_public_key_from_raw”
Why should we do this step?
Thanks a lot!
ECDSA is used for the Nordic Secure bootloader. It uses the nrfutil tool to generate the private key and generate the public key.
After that on the bootloader, it uses the public key and verified with received firmware (encrypted by nrfutil). You can have a look for reference.
This is standard of the ECDSA on the market. You can also find any document from web.