Is there any way to reject GZP System Address Request?

[kiterai]

I'm using the nRF52840 and Gazell Pairing (GZP) to develop a device network.

Because I need bi-directional communication, I am not using GZP's encryption feature, as it does not support host-to-device communication when encryption is enabled.

When encryption is enabled, I can reject a Host ID request. However, in plaintext mode, communication is established as long as the System Address Request succeeds, and there doesn't seem to be a way to reject it. This means that any device can pair with the host and send packets at any time. I can't implement a "pairing mode" vs. "normal mode" behavior.

Is there any way to accept or reject a System Address Request in GZP? Alternatively, is there a way to enable host-to-device communication while still using encryption?

[Hung Bui]

Hi Kiterai, 
You are correct that when using encryption it's not possible to send ACK back as the ACK is used to send the AES counter. See here: Gazell bi-directional communication between paired devices

As far as I remember in the HID application (the main use case for Gazell pairing) we use a unencrypted channel to send data from the host to the device , for example to turn on Caplock. 

How do you assign the unencrypted pipe to the devices ? Can you reject a packet from a pipe that has not been assigned ? 

As far as I know there is no encryption or protection in Gazell link layer to avoid unwanted device to send a message or to know the channel mapping. So it doesn't mater if you can reject System Address Request, an attacker an always listen to a channel and get the address and the timing of the channel to transmit data. 

I'm thinking of you may need to implement another layer of encryption on the unencrypted pipe. We didn't have this problem because on the HID application the opposite direction was not very critical (to send CAPLOCK, NUMLOCK to the keyboad). 

[kiterai]

Thanks for your answer.

Since I'm using GZP, I believe it assigns pipes automatically. Although I don't fully understand the internal implementation of GZP, I can ignore packets from devices that haven't been paired.

My main requirements are bi-directional communication, support for multiple devices, and the ability to reject packets from unpaired devices. I'm not particularly interested in encryption itself. But if I understand correctly, you're saying that rejecting packets from unpaired devices requires encryption. Is that correct?

I'm also not sure how I could implement another encryption layer. If I were to do that, how would it work?

- Would it be built on top of the Gazell Link Layer, or on top of GZP? Would I need to manage the pipes manually, such as by setting base addresses?

- Are packets automatically filtered by Gazell, or would the added layer need to inspect packets and forward only the valid ones? Would the host still send ACKs to invalid devices?

[Hung Bui]

Hi Kiterai, 

kiterai said:

But if I understand correctly, you're saying that rejecting packets from unpaired devices requires encryption. Is that correct?

Correct, without encryption the GZL will accept any host that has correct address and use the correct channel in the correct time. 

kiterai said:

- Would it be built on top of the Gazell Link Layer, or on top of GZP? Would I need to manage the pipes manually, such as by setting base addresses?

You can choose to build it on top of GZP or GZL (note that GZP code is available and you can modify it). But I am afraid the Gazel link layer will just send ACK back on any packet sent to the correct host address and correct pipe. 

kiterai said:

- Are packets automatically filtered by Gazell, or would the added layer need to inspect packets and forward only the valid ones? Would the host still send ACKs to invalid devices?

As I mentioned above GZL link layer will just ack to any packet. 

Note that you can not control ACK but you can stil control of the packet is from a valid device or not using your own proprietary encryption/pairing. 

To be able to control the ACK, I think you would need to start your own protocol based on top of ESB (which Gazel based on top). ESB doesn't have encryption or channel hopping. 

Another option you can look at is BLE. Gazel is quite old protocol and it's made focusing heavily on mouse&keyboard application.