Sentinel Dongle Key + udev

Working on Apalis iMX6Q 1Gb Rel 1.1Y, Ixora board, BSP 6.4.0 Multimedia Reference Image.

Problem: I cannot login to a Sentinel USB Dongle Key. The reported Error is 07 = Sentinel protection key is no longer available.

But I have to detail:
Previous version of the machine on which I’m working was based on Apalis iMX6 Rel. 1.1B and an old Boot2Qt OS (kernel 4.14.159) with udev as device manager. We manged 2 different Sentinel Keys, one marked “PRO H” where the manufacturer was “Safe Net” and one marked “PRO DL”, the manufacturer was “Gemalto” and it is newer that the PRO H. For info: now Sentinel keys are owned by Thales.
For each one we have a dedicated HASP library for Linux ARM and on both we can load libraries and login/logout with success.

Now we work on the BSP 6.4.0 OS, udev is the device manager and:

  • with the PRO DL key (newer one) we can load the same library as before and can login/logout
  • with the PRO H key (older one) we can load the same library as before BUT CANNOT login/logout

Inputting some commands like “lsusb” and “udevadm” on both OS versions and on both Sentinel Keys it seems both OSes correctly manage both keys, the only relevant difference is that the newer key is viewed as HID and the older one have no driver assigned.
Reading on the Internet I found some people have similar problems with old Sentinel keys and they work around with udev rules.
I made my tries by adding udev rule like:
SUBSYSTEM==“usb”, ATTRS{idVendor}==“0529”, ATTRS{idProduct}==“0001”, GROUPS=“root”, MODE=“0660”
or simpler one:
ATTRS{idVendor}==“0529”, MODE=“660”
but this not only does not resolve the PRO H key problem, it blocks the PRO DL one too: same login ERROR 7 (instead of 0=SUCCESS) on PRO DL.

Can someone give a suggestion on how to input a udev rule that give full access to every 0529 idVendor plugged device?
Or if the problem could be on another side?

Thanks,
Pipe

Hi @Pipe ,

I think that the udev rules you’re using are restricting access to non-root users: MODE=“0660” gives read/write access to the user (in this case, root) and to its group. You could try a weaker permission like MODE=“0666”, though I’m not sure this will solve the problem or if that implies any security risk.

As for the problem itself it’s hard to know for sure. It looks like the old key has some missing drivers the newer kernel doesn’t have. I’d recommend you contact Thales about the supported kernel versions for this key and any additional steps to support it on Linux ARM.

Best regards,
Lucas Akira