Changing BLE Encryption Algorithm

[Michael Monteiro]

Hello everyone,

I'm working on a project to change the BLE encryption algorithm from AES-CCM to NTRU. Do someone have an idea of where to start from?

I would appreciate any help.

Thank you in advance!

Sincerely,

Michael Monteiro

[Matthias Ringwald]

Hi Michael

I haven't heard about NTRU before, but this looks like an interest idea. Some comments.

Using BLE encryption is an optional feature, so a first approach could be to only encrypt the ACL packets sent between hosts. For BTstack, this could be hacked into hci.c, or a virtual HCI transport layer could deal with encryption/decryption of ACL packets. Such a transport encryption would need to keep track of what connections exists and what keys to use for that but would be portable and run on all supported platforms.

The AES-CCM in BLE uses a 16-byte Long-Term Key. This key is exchanged/created using the BLE Security Manager Protocol. If NTRU also uses a (less than) 16 byte key, the BLE Security Manager could be left in place. If not, depending on how NTRU creates symmetric keys, it might need some patching. For asymmetric keys, this would require new SM PDUs as well, I guess

All Bluetooth Controllers implement AES-CCM as part of their link layer. Usually, you don't have access to these. However, open-source link layers exist. If you want to actually replace AES-CCM, I would suggest to pick one of them that run on nRF5x silicon. The most known example for this is the Zephyr OS that includes a full BLE link layer. Another one is MyNewt. For this, timing will become a critical part as most LE Controllers provide at least AES128 if not full AES-CCM in hardware.

Best
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/cc840626-98d6-4be4-a5ad-0b94d57f79e2n%40googlegroups.com.

[Michael Monteiro]

Hi Matthias

Thank you so much for your comments.

I've been trying to change the AES in Zephyr OS and I actually found where to replace, but for reasons of not having compatible hardware at the moment I decided to go on the first approach you sugested, encrypting only the ACL packets. Should I implement all the encryption algorithm into hci.c or implement into the Security Manager and then make a call in hci.c in some way?

Thank you again for your help!

Sincelery,

Michael Monteiro

[Matthias Ringwald]

Hi Michael

As mentioned before, you could add ('hack') it into hci.c or implement a virtual hci_transport.h layer, that is put between hci and the actual hci transport. It sees all packets and could encode them.
Do you need to add data to each ACL packet, e.g. a packet counter or some other id? AES-CCM has an implicit counter that is not set. You could do this as well, but counting per HCI Connection would need to be done in hci.c. So, I guess hci.c is the easiest way to start. If needed SM can provide HCI with the necessary crypto data.

Best
Matthias

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/8cf5d9a3-d071-4bfd-b692-0ae934cdf9ddn%40googlegroups.com.

[Michael Monteiro]

Hi Matthias

I've been working a little with the idea of encrypting the ACL packets, I made some changes in hci.c as you sugested, I just don't know if I'm going in the right implementation direction.

I made basically three modifications:

- I declared four global variables in the file, related to the key generation process, (I didn't find a way yet to pass it as parameters to a function)
- I modified the hci_send_acl_packet_fragment function to encrypt every ACL packet fragment before sending

- I modified the acl_handler function to decrypt the ACL packets, but I'm not sure if it will recombine well after the decryption, actually

Do you have any comment? Anything I might be doing terribly wrong?

[Matthias Ringwald]

Hi Michael

As I don't know NTRU, I can only guess. You're approach doen't sound wrong - if NTRU works independent from the way the data is segmented.

When you encrypt an ACL packet, you should only encode the ACL payload (there's a 4 bytes HCI header). This also applies to fragmentation. Because of this, I'd suggest to encrypt it in hci_send_acl_packet_buffer. Similarly, I would first let BTstack recombine the packet before it gets decrypted.

Best
Matthias

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/2f9bed5c-ca95-4657-93d0-5fdbf379c8f1n%40googlegroups.com.

[Michael Monteiro]

Hi Matthias

Thank you again for your help. I think I'm closer now than never getting it done.

One question I have is, hci_stack->hci_packet_buffer do have the 4 bytes HCI header you mentioned? If yes, how can I separate it from the payload?

Sincerely,

Michael Monteiro

[Matthias Ringwald]

Hi Michael

The HCI ACL header I've mentioned is at the first 4 bytes of hci_staxck->hci_packet_buffer. You can just skip it when encoding/decoding the payload (from offset 4).

Best
Matthias

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/311d6253-66f9-44c2-bdac-d0833ea5eed5n%40googlegroups.com.