Disabling doesn't turn off OTP in mode 6 on NEO-n

Question

Disabling doesn't turn off OTP in mode 6 on NEO-n

Closed this issue 9 years ago · 13 comments

I have a NEO-n... If I use the manager or personalize to enable all of CCID, U2F and OTP, the disabling doesn't actually disable OTP. This is ykpersonalize -m6 and is now supported on the NEO-n (and others). Setting this changes the product id to 0x116, and when changing that in the preferences yubiswitch reports no errors and claims to enable/disable the yubikey, but a casual touch still spits my OTPs out.

Answer 1 · 2014-12-13T00:33:21.000Z

Thanks for reporting. I will need to buy a NEO-n to repro this.

Answer 2 · 2014-12-13T00:43:14.000Z

Happy to buy you one, if you'll try to fix it!

Answer 3 · 2015-01-07T05:28:10.000Z

Also happening for me. I have updated the product id to 0x0116 and yubiswitch stops complaining that it can't find the device, but it fails to prevent accidental touches.

Answer 4 · 2015-02-13T03:47:48.000Z

I've fixed this (and likely broken it for other yubi devices) in my fork: https://github.com/postwait/yubiswitch

Annoyingly, due to the need for getting all up in the HID interface, it needs to be run as root... so:

sudo /Applications/yubiswitch.app/Contents/MacOS/yubiswitch

Aside from that, it works well for me.

Answer 5 · 2015-02-13T12:52:52.000Z

👍

I will try this on my box with the old yubikey, to see if it still works. Is there really no other option than running as root? :(

Answer 6 · 2015-02-13T12:53:28.000Z

also, can you make a pull request?

Answer 7 · 2015-02-13T13:33:49.000Z

Do you really want a pull request? It very likely breaks other yubi devices (that don't present as full HID) and you can't just "click to run" as it has to run as root. It would need a lot of work to be presented to the normal user. If so, I'm happy to issue a PR.

Answer 8 · 2015-04-01T19:18:21.000Z

Newb looking around... Which part of working with the HID interface requires kIOHIDOptionsTypeSeizeDevice?

Answer 9 · 2015-05-25T17:22:38.000Z

I merged @postwait PR and am working on factoring out HID logic into helper service

Answer 10 · 2015-08-16T20:37:49.000Z

hey @postwait, I've finally got some time to work on this, I've pushed a few commits. I'd appreciate if you could test this with your NEO-n.

Basically I've refactored your code and move it to a privileged daemon, the main apps makes sure it's launched by launchd with privileged root permissions (so that it can talk use HIDmanager properly). The main apps talks to the daemon via XPC calls.

Answer 11 · 2015-08-16T22:03:16.000Z

you can download release 0.9

Answer 12 · 2015-08-17T03:02:01.000Z

I am uncomfortable having to run an agent as sudo here. Fortunately, I found an alternate solution using Karabiner (which, yes, runs as a privileged kernel extension but it's a piece of software that has already earned my trust in the past). Others who are curious can check out pqrs-org/Karabiner-archived#454. It ended up being a lot more flexible and suitable to my needs that Yubiswitch in the end.

Answer 13 · 2015-08-17T06:27:18.000Z

Good you find a solution! :)
On Mon 17 Aug 2015 at 04:02 Bo Jeanes notifications@github.com wrote:

I am uncomfortable having to run an agent as sudo here. Fortunately, I
found an alternate solution using Karabiner (which, yes, runs as a
privileged kernel extension but it's a piece of software that has already
earned my trust in the past). Others who are curious can check out
pqrs-org/Karabiner-archived#454 pqrs-org/Karabiner-archived#454. It
ended up being a lot more flexible and suitable to my needs that Yubiswitch
in the end.

—
Reply to this email directly or view it on GitHub
#23 (comment)
.