NFC support Zephyr voor LE OOB secured pairing...


frv
 

Hi all,


As far as I can see there is no real support for NFC in Zephyr. 

Correct?


I'm really getting stuck in the LE OOB pairing process... 


I would really feel a pity I will need to fallback to the Nordic proprietary SW stack for my entire BLE design.

Meaning running on the Linux board the Nordic PC BLE driver (serialization protocol) for setting up the BLE central application combined with Nordic BLE connectivity(UART H5) and running a Nordic API based BLE peripheral applic that has direct NFC support.


Best regards,

Frank


Rodrigo Peixoto
 

Frank,
I have a piece of code that wakes up the MCU through NFC, but I could not write or read data from it yet. We are using only the HAL code. The only tricky is to register the interrupt with IRQ_CONNECT for avoiding spurious interrupts. Have you tried to use the HAL?

On Mon, 21 Jan 2019 at 06:07 frv <F.Vieren@...> wrote:

Hi all,


As far as I can see there is no real support for NFC in Zephyr. 

Correct?


I'm really getting stuck in the LE OOB pairing process... 


I would really feel a pity I will need to fallback to the Nordic proprietary SW stack for my entire BLE design.

Meaning running on the Linux board the Nordic PC BLE driver (serialization protocol) for setting up the BLE central application combined with Nordic BLE connectivity(UART H5) and running a Nordic API based BLE peripheral applic that has direct NFC support.


Best regards,

Frank

--
Rodrigo Peixoto
Co-founder and Technical guru

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex

.


frv
 

Hi Rodrigo,

No not yet...
So far I'm still in the process of trying to understand how the NFC message (as described by the Bluetooth SIG) gets into the Bluetooth SW stack for the OOB pairing process. 
Nor on Linux/BlueZ, nor on Zeyphyr/bluetooth this is clear to me.
 
Depending on the track we will take, honestly I would love to continue with Zephyr for our BLE architecture, I can focus more on the Zephyr solution if that is the way to go. 
The alternative is to go fully Nordic also for the BLE SW stack. 

Thanks for your feedback. 

Best regards,
Frank


Rodrigo Peixoto
 

Frank,
as far as I know, there are some functions that are being called during the provisioning process like "static int output_number(bt_mesh_output_action_t action, u32_t number)". This function (in my code at least) prints the OOB value for pairing. I would suggest you take a look if there are alternatives to that or maybe use this function to call your NFC tag writing one showing the OOB value to the provisioner. You can find some samples where people blink a led with the OOB value, it works as well. 

I hope it helps.

Best regards,
Rodrigo Peixoto
Co-founder and Technical advisor

+55 (82) 98144-8585
http://ayna.tech | Skype: rodrigopex




Em seg, 21 de jan de 2019 às 07:45, frv <F.Vieren@...> escreveu:

Hi Rodrigo,

No not yet...
So far I'm still in the process of trying to understand how the NFC message (as described by the Bluetooth SIG) gets into the Bluetooth SW stack for the OOB pairing process. 
Nor on Linux/BlueZ, nor on Zeyphyr/bluetooth this is clear to me.
 
Depending on the track we will take, honestly I would love to continue with Zephyr for our BLE architecture, I can focus more on the Zephyr solution if that is the way to go. 
The alternative is to go fully Nordic also for the BLE SW stack. 

Thanks for your feedback. 

Best regards,
Frank


frv
 

Hi Rodrigo,

Thanks for your valuable feedback. I will have a look at it and see how far I can get.

Best regards,
Frank


Johan Hedberg
 

Hi Frank,


On 22 Jan 2019, at 10.01, frv <F.Vieren@televic.com> wrote:

Hi Rodrigo,

Thanks for your valuable feedback. I will have a look at it and see how far I can get.
Note that the APIs Rodrigo referred to are for Mesh provisioning, not for pairing. Zephyr doesn’t currently expose any OOB APIs for pairing, except bt_le_oob_get_local(), which only returns the local connectable address. I don’t think anyone would object to extending the pairing API with full OOB support however, so if you’d like to work on it the contribution would be very welcome.

Johan


frv
 

Hi Johan,

I was already aware this part was missing... :(. 
Unfortunately for the moment we are on a very strict time schedule to come up with a BLE architecture for our near future wireless HealthCare solutions. Time to market has become crazy in the last years. More and more we need to rely on finished building blocks to implement our solutions. Just like playing with Lego :). 

In the last 4 months I have intensively compared and investigated different BLE HW (Nordic, Laird, uBlox, ...) and SW (QT BLE, BlueZ, Zephyr, Nordic ...). So far I'm still in the process of understanding BLE and especially its secrets regarding "security". So far my expertise was in wired solutions, VideoOverIp (10G fiber systems) with limited security requirements. 
 
So far it seems that only brand proprietary BLE solutions (E.g. Nordic)  support a complete solution that implements all our requirements. Especially security is high on our list of requirements for implementing wireless BT health care systems.
For prototyping regardless of security I came up with a BLE architecture based on Zephyr (for the BLE peripheral device)  and BlueZ/QT (for the BLE central device), as HW platform we will likely stick to/select Nordic. 

Best regards,
Frank

 


Joakim Andersson
 

Hi Frank.

For NFC support with Zephyr on the Nordic HW can you have a look at the nRF Connect SDK  (https://www.nordicsemi.com/Software-and-Tools/Software/nRF-Connect-SDK)

For OOB support in the Zephyr Bluetooth stack this part is missing so that will have to be added.
If you create an issue for this feature on the zephyr github project someone can pick this up, or you can contribute it yourself.

OOB would have to be input into the pairing procedure in a similar way as the passkey, so for prototyping your system maybe you could use passkey instead until OOB support has been added.


frv
 

Hi Joakim,

Thanks for your feedback on the topic.

Indeed currently I'm using "passkey authorization" during the pairing process. Although I don't have a keyboard or display on my BLE devices I have created an "automated pairing" process based on passkey verification.

On my Zephyr board acting as BLE peripheral I set a random generated passkey (6 digits).

static void auth_passkey_entry(struct bt_conn *conn, unsigned int passkey)
{       
        bt_passkey_set(random_key);
}

This passkey will be transmitted encrypted by AES 128 via the BLE advertisement. Only a BLE central device having the same private  AES key will be able to decrypt it.

On my BLE central I'm running a BLE QT application that manages to set the passkey automatically without user interaction. When the BLE central tries to pair with the BLE peripheral (Zephyr), the BLE central application injects automatically the passkey (BlueZ Dbus API) when asked.  

So I just need the NFC process on the Zephyr board for receiving the private AES key during the commissioning phase. 

Best regards,
Frank