LibLogicalAccess 1.81.0 for KeePassRFID plugin
Closed this issue · 23 comments
Hello,
Is there a way to download compiled windows binaries for version 1.81.0? It seems all download links were taken down and no longer available. I wanted to use that specific version for the KeePassRFID plugin but I have trouble compiling it, probably due to different version of Visual Studio (1.81.0 suggests that older version should be used).
The original link was:
http://artifacts.islog.com/repository/rfid-releases/eu/islog/lib/readers/liblogicalaccess-exe/1.81.0/liblogicalaccess-exe-1.81.0.zip
Alternatively, can anyone share just the DLLs required for KeePassRFID? Thanks
Yes indeed, the COM wrapper of LibLogicalAccess has been deprecated since a while now and binaries are not available anymore.
We instead now use the SWIG wrapper which is open source and in theory portable (https://github.com/islog/liblogicalaccess-swig).
I just updated the keepassrfid plugin code to use it as well. I also quickly created a release for the occasion https://github.com/islog/keepassrfid/releases/tag/2.0.0. Hope it helps.
@Maxhy Thanks for the update! I really lost hope that any update are possible after this time :)
However, the plugin does not seems to be work anymore as it throws the following error:
It can't find the LibLogicalAccessNet.dll - Such DLL is not present in the SWIG release you provided but the closest thing seems to be LibLogicalAccessNet.win32.dll which I tried renaming but with no luck. Actually I tried putting every dll there is but with the same result. Also tried both x86 and x86_64 release files and with two different KeePass versions: 2.49 and latest 2.50 (But both are were x64 releases, however I don't know how this affects plugin usage).
Also, previous version of the plugin (v1.0.0) did not throw this error and was working with both 2.49 and 2.50 x64 but obviously shown a message that no reader could be found and LibLogicalAccess is not installed - but it wasn't a plugin crash, just standard message.
Is there any way you could help with this? I would appreciate any hints :)
Thanks for testing. Ok I will take a look later, probably a bad plgx packaging. Otherwise for now the LibLogicalAccessNet.dll is inside the nupkg Nuget package. I have extracted and added the raw file on the LLA Swig release to make things simpler.
@Maxhy
Thanks for the extracted DLL.
I managed to figure out which path was KeePass looking in for the dll file, it seems it was getting it from the HintPath but combined with %AppData%:
<HintPath>..\packages\LibLogicalAccessNet.2.4.0-RC1\lib\netstandard2.0\LibLogicalAccessNet.dll</HintPath>
However, after putting the DLL file there, KeePass threw a different error:
When translated, it basically means 'operation not permitted due to current state of the object', tried both 2.49 and 2.50 versions of KeePass.
Unfortunately my knowledge ends there. Do you by any chance know what might cause this error?
Mhhh indeed, I tested DLLs and it worked but not the plgx. I guess we have issue with the swig generated wrapper here not being properly interpreted by KeePass. Not sure it can be fixed...
For now you should copy the KeePassRFID.dll instead into KeePass plugin folder (with LibLogicalAccessNet.dll). Then extract x86 or x64 dlls from liblogicalaccess-swig-bin.zip into a directory (eg. c:\lla-swig) and add this directory to the path. I would definitely prefer a plgx file to hold all these files and avoid dealing with path....
Ok it appeared that PLGX packaging was failing because of netstandard reference being a different version. I removed the strong name reference and that fixed the issue of PLGX loading. You still need to copy native dlls of LLA manually for now.
Check https://github.com/islog/keepassrfid/releases/tag/2.0.1
@Maxhy
Thank you! Both DLL release and the latter PLGX now work (but I just used path for the DLLs as I'm not sure which of them are required and didn't want to put everything into KeePass directory) and KeePass recognizes the plugin and let me choose RFID Key Provider.
But now I've got another issue :) When I place the Yubikey on the reader and try to unlock, completely nothing happens, at least not on the KeePass side. The reader flashes the LEDs but KeePass does not seem to recognize anything and stays on the unlock window (but all subsequent clicks do not make the reader LEDs flash anymore). Is there any configuration for the plugin? The reader I use is Omnikey 5027 - Yubikey is correctly recognized in Omnikey Workbench so at least we I know the reader works to some extent.
@Maxhy
OK, I've found the configuration (was looking under plugin settings while it has it's own menu entry). I was able to choose PCSC provider where my reader was visible. However, choosing Chip SN results in the behavior I described above (completely no reaction) while NFC tag says "Unsupported NFC Tag". Chip SN also does not work when creating new database, nothing happens when trying click "Next" after selecting KeePassRFID as a Key Provider.
Also - if I understand correctly - KeePassRFID only let me use Chip Serial Number (in this case Yubikey SN) as a password? I won't be able to use the Challenge-Response feature?
ok good, you're moving forward 😃.
Yes that's correct, the plugin is designed to support:
- CSN as a password (recommended to use password + rfid card here then). I just tested that one with a Yubikey NFC and it works on my side. Which PC/SC reader are you using here?
- Store a password on a NFC Tag.
- #5. Not implemented today but would be the most robust solution for "passive" encryption, just need some votes for proper implementation as I wasn't sure people outside myself were interested about such plug-in.
When the plug-in was created the Yubikey product with NFC support wasn't much deployed around me and solutions of OTP over NFC didn't have much market share. So no sorry there is no support of Challenge-Reponse feature here. To be honest I'm not sure how it would work as the plugin needs to provide something that could be used for symmetric encryption/decryption and Challenge-Response is not designed for that purpose (it always change).
As I mentioned before I'm using Omnikey 5027. Omnikey Workbench correctly recognizes Yubikey as Yubikey (shows name, ATR and other stuff) so I assume the reader is fine. Which interfaces do you have configured on your key? (This can be checked in the Yubikey Manager)
As for the Challenge-Response this is the method directly suggested by Yubico themselves (Check HERE) for KeePass encryption.
In fact, there is a KeePass plugin which supports it via USB: KeeChallenge, it's on GitHub right here:
https://github.com/brush701/keechallenge. However, on PC this works only via USB.
Surprisingly though, on Android there is ykDroid (also on GitHub, here: https://github.com/pp3345/ykDroid) which uses Challenge-Response through phone's NFC. Maybe this can be somehow ported to PC?
I use such setup everyday (KeeChallenge on PC, ykDroid with KeePass2Android on my phone) with the exact same database and works without any issues.
Is there any chance of implementing this in future? This would allow usage of Yubico suggested method for existing databases, I guess more people would be interested in this.
Thanks for all the details @kaczorws. Indeed I missed that line where you said Omnikey 5027. This reader is well supported so it is not a reader compatibility issue. During my tests I had all interfaces available enabled over NFC. On Omnikey Workbench, do you have proper data on "UID" field?
I need to document myself more on that Yubikey details but it may be a way to use Challenge-Response then. I guess it will be standard ISO7816 APDU commands. I will create a dedicated ticket for that, thanks.
@Maxhy
Thank you for considering implementation of this. This could lead to much wider usage of the plugin.
As for my reader, it seems Workbench do not show the UID field, only ATR and some other stuff. I checked the HID documentation and UID field in fact should be shown. I tried 2 different Workbench versions:
v1.81.955:
v2.2:
As you can see second one correctly shows this is a YubiKey so I guess something is recognized. I tried enabling all NFC interfaces on the key but the result in Workbench is always the same, exactly as the behavior in KeePass (nothing happens apart from reader LED flash). Do you have any idea what could be the issue here?
Mhhh not sure what is happening on your side. I tested with Yubikey 5 NFC as well, FW 5.2.4.
I guess you installed the Omnikey 5027 drivers (Windows CCID driver do not work well for this reader afaik)?
Yup, I have the latest CCID drivers from HID installed:
Which Workbench version are you using? I could try that specific one.
I tried with 1.8.1.955 as well...
Can you give a try with another reader or try to read the UID using your Android phone and an app like NFC TagInfo?
OK, I tried NFC TagInfo on the phone and it showed me UID without issues, so it must be some problem with the reader. Which reader are you using? Is it the Omnikey series? From what I gathered on the web, most people are using Omnikey 5022 with the Yubikey. I looked on the HID website and 5022 and 5027 seems to have exactly the same specification, albeit 5027 comes 'preconfigured' whatever that means.
Well I have a bunch of readers from different manufacturers but I daily use Omnikey readers. I prefer Omnikey 5022 or 5427 units but 5027 can be fine if not a specific revision (there is different flavors of the 5027 readers on the market, details are coded on the label behind).
Omnikey 5x27 are a bit special as they are 'preconfigured' to read most used credential types and output the identifier into keyboard output. I guess if you're seeing it as a PC/SC reader it means you disabled the Keyboard feature with Workbench, which is required (that's for 5027, on Omnikey 5427 readers you usually configure through the embedded web interface instead).
The one I have is 5027CK according to the Workbench:
The back says only 'C' but it looks like it did not fit on the label:
And yes, I disabled the Keyboard Wedge in the Workbench and then it was recognized instantly as a Smartcard reader in Windows but I still did not find a way to make UID show up. I tried different driver versions and different Yubico keys but only ATR is being shown.
What bothers me is that in Workbench in Diagnosis -> File Versions I can see only Microsoft drivers:
Shouldn't HID drivers be there as well? I've seen in some HID documentation that HID drivers are also there (where Vendor is HID instead of Microsoft).
Which version of Windows and HID CCID drivers are you using? Do you see HID drivers in Workbench?
Ok... I will give a try next week and let you know.
I've made small changes to use Yubikey 5 as a NFC tag as well. The password will have to be set first following https://support.yubico.com/hc/en-us/articles/360016614700-Setting-the-NDEF-Slot-for-NFC-Usage.
It needs a new version of LLA SWIG as Yubikey expect P2 from SelectFile command to be set to "First Record" and it wasn't the case. Otherwise the new "Force Card Type" option added with KeePassRFID v2.1 would have been enough to work if set to "ISO7816"... The new LLA SWIG release will take a few weeks here.
@Maxhy
Thank you for the update - so the issue is strictly with Yubikey 5? If I understand correctly, the NFC slot is set default to 2?
I tried the new 2.1 plugin version and changed Force Card Type to ISO7816 but still there is no difference - but from I get, this is because I haven't changed the NFC slot with the guide you provided?
As for my 5027 reader - I made some more tests but what's most important I finally read the official HID documentation. And what is most interesting, the 5027 specifically works in CCID mode only when Omnikey Workbench is running in a background.
This explains why the plugin only sometimes discovered the reader - it was related to the Workbench running. Also, what's even more interesting, the official 5027 documentation doesn't show the UID field either:
I then tried other tools, like "PC/SC Reader Diagnostic Tool" which allows to manually put APDU commands. I found that UID is returned by using command "0xFF, 0xCA, 0x00, 0x00, 0x00" but unfortunately that returns response "6A 81" which means "Function not supported". So I'm not sure if this is something related to the reader or the key itself now.
OK, just a little update, I finally confirmed that the reader is working - I added the key as U2F in several accounts and can unlock them using NFC without any issues. Both reader and the key are seen by the web browser and unlock everything as should.
So it seems that either the plugin is not compatible with the 5027 model or it's the Yubikey 5 specific issue but still that only affects the plugin only - Everything else is working. Please let me know if my assumptions from previous posts are correct (Yubikey 5 default slot case) so I can test it further.
Else let me know if this should be added as separate issue in GitHub as we are discussing it in long closed case about something else :)
Mhh looks like I need to do more test with Omnikey 5027 here but the behavior you describe with Workbench is weird tbh. I checked and I only have Omnikey 5127 CK and Omnikey 5427 CK left so I cannot test unfortunately.
For the second comment, the apps you tested are either using U2F with FIDO2/OTP (#8) or NDEF (will work only once new release of LLA SWIG available) I guess and not the CSN (as FFCA000000 APDU command fails). Right?
As it is mentioned in the 5027 documentation, it only works in PC/SC mode when Workbench is running. This seems to be done by design so the Keyboard mode would be default (as Keyboard mode is the special feature of 5027 and the reason why it is more expensive) and if someone really wants the PCSC on 5027 (like me) then Workbench is the only way. With Workbench running it behaves like standard 5022. So I have just put the Workbench in autostart and forced it to go to tray using some other tool so it doesn't bother me.
And since now I have confirmation that reader is working (I just missed the part that Workbench should be running in background) and have it working with with browsers for FIDO functionality, the only thing missing is the OTP HMAC-SHA1 Challenge-Response support so existing KeePass databases could be opened on every platform through NFC.
Is there a chance that this (HMAC-SHA1) would be added at some point?