What do you mean by “key works on other computers.” ?
Tried a laptop with Windows 11 and also Linux under Raspberry PI.
What Windows version ?
Windows 10 Pro, 22H2. OS Build: 19045.6456
Device Name Z600-WorkStation
Processor Intel(R) Xeon(R) CPU X5650 @ 2.67GHz 2.66 GHz (2 processors)
Installed RAM 40.0 GB
Storage 466 GB SSD WD Blue SA510 2.5 500GB, 932 GB HDD TOSHIBA DT01ACA100
Graphics Card NVIDIA Quadro K2000 (2 GB)
Device ID – redacted –
Product ID – redacted –
System Type 64-bit operating system, x64-based processor
Pen and touch No pen or touch input is available for this display
Any other devices connected ?
There is a USB YubiHSM, and mouse and bluetooth dongles.
Infeon Smart Card Reader works with this computer - but not in use at the time.
Also running SoftHSM
Did it work before ?
Not on this computer. No.
What was the last thing you did with the device ?
This was a brand new key. We did initialize it now on the raspberry where it works without issues.
Windows Event viewer on the problem machines shows the errors - shared earlier. This is the machine where it’s needed - it’s the development machine with applications needings the HSM.
How do you access this machine ? Are you working locally or remotely on the machine ?
Does the Nitrokey-HSM show up as Smartcard Reader in the device manager ?
Windows maps Smartcard Readers from the client to the remote machine, potentially hiding cards connected to the remote machine. If you connected remotely, then this might explain why the Nitrokey is not visible.
This is a development machine which I could access directly. But I am remotely logged in to this machine most of the time and definitely all the time we tested the NitroKey.
On the Device Manager it shows as an unknown device. But that is also the case on the laptop where it does work.
I will investigate using the NitroKey while remotely logged in. It’s actually a very smart observation.
Great news - connected directly to the machine - the Nitrokey springs into life - works fine.
I will try to put it through its paces - but yes the issue is remote login.
Both Remote Desktop Protocol and Citrix have their own concepts of smartcard device redirection.
With Citrix it is even impossible to access the cryptographic device attached to the host from the remote session - user’s remote session on the server sees only devices attached locally to the remote station you are connecting from.
I wouldn’t be surprised if all works fine if you attach the Nitrokey to the machine you are connecting from.
Yes, that seems to be the case
I would be happy if the HSM stays local to the device it’s connected to and that remote login does not export it or affect its access locally.
That would seem to make the most sense and I think one other USB based HSM we tested was not affected by remote login.
Also in our case - we were connecting from a mac to a windows m/c which may have complicated matters even further. I am not sure if this was under RDP from Mac or Royal TSX (another product which we have used recently to remotely login)
Not sure what control a USB device (or its driver) has on what happens when there is a login session but also since the NitroKey or its underlying tools at least seem to have their origins in smart cards - i guess it was desirable in that case to export/import the device during a remote login session. Just speculating - this is beyond my technical expertise.
I guess the typical use case for Windows Terminal Server or Citrix is to have a single server (cluster) serving thousands of users, therefore it would not be desirable that they can access USB devices on the host like this.
I am afraid Nitrokey can do nothing for you here; you might try some other solution to access the key remotely, such as some USB-over-IP solutions or something like p11-kit remote, if you get it to work and PKCS#11 interface is the right for you.
the remote login was just to access a development machine - and in production maybe someone is logging in for maintenance
Its not intended to be a way to serve multiple users - that would be a layer on top
But i see your point - just pointing out that it’s not our architecture ..
|