Is there any way to reject GZP System Address Request?

RE: Is there any way to reject GZP System Address Request?

Hung Bui — Wed, 18 Jun 2025 11:11:55 GMT

Hi,
Glad that you find a solution. Feel free to reopen this ticket or create a new ticket if you have further question.

RE: Is there any way to reject GZP System Address Request?

kiterai — Wed, 18 Jun 2025 09:04:41 GMT

You have helped me a lot. I decided to implement pairing layer on Gazell Link Layer by oneself.

Thank you!

RE: Is there any way to reject GZP System Address Request?

Hung Bui — Thu, 12 Jun 2025 09:01:56 GMT

Hi Kiterai,

[quote user="kiterai"]But if I understand correctly, you're saying that rejecting packets from unpaired devices requires encryption. Is that correct?[/quote]

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

[quote user="kiterai"]- 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?[/quote]

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.

[quote user="kiterai"]- 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?[/quote]

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.

RE: Is there any way to reject GZP System Address Request?

kiterai — Wed, 11 Jun 2025 09:00:13 GMT

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?

RE: Is there any way to reject GZP System Address Request?

Hung Bui — Thu, 05 Jun 2025 13:54:13 GMT

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).