yubico/yubikey-personalization

YubiKey Personalization cross-platform library and tool

yubikey-personalization's Issues

support reading data from standard input

Feedback from UDS: the tool should be able to read configuration data (e.g., secret key) from standard input and not from command line due to security issues (secret key ends up in bash history, ps output, etc).

Long-term the input format to use would be PSKC (RFC 6030), however a simpler scheme to use would be useful to show on web browser for users to paste into a terminal screen. Maybe simplest is to use the same input format as the output format.

typo in Makefile.am

there is an typo in Makefile.am and the relative path prefix to libhmac.la is missing

index 79f9c95..a99fed5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -58,10 +58,10 @@ libykpers_1_la_SOURCES += ykpers-nojson.c
 endif
 libykpers_1_la_SOURCES += ykpers_lcl.h ykpers-json.h ykpers_lcl.c
 libykpers_1_la_SOURCES += ykpers-1.pc.in libykpers-1.map
-libykpers_1_la_LIBADD = $(LTLIBYUBIKEY) ./ykcore/libykcore.la libhmac.la $(libjson_LIBS)
+libykpers_1_la_LIBADD = $(LTLIBYUBIKEY) ./ykcore/libykcore.la ./libhmac.la $(libjson_LIBS)
 libykpers_1_la_LDFLAGS = -no-undefined \
        -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
-EXTRA_libykpers_1_la_DEPENDENCIES = libykpers-1.map
+libykpers_1_la_DEPENDENCIES = libykpers-1.map

 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = ykpers-1.pc

Static Password setting doc error

In the documentation (README), it states to do the following if you want to set a static password on slot 2:

./ykpersonalize -ofixed=cccccccccccc -a00000000000000000000000000000000 -2

However, it says upon executing the command You must choose slot before any options (-o).

Someone mind updating the doc to have -2 before -ofixed? Thanks =)

Don't use deprecated libjson-c symbols

After upgrading to libjson-c 0.11 I noticed a couple of warnings that I suppose we ought to fix by using some other symbol instead.

/Simon

../ykpers-json.c: In function '_ykp_json_import_cfg':
../ykpers-json.c:199:3: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *yprod_json = json_object_object_get(jobj, "yubiProdConfig");
^
../ykpers-json.c:200:3: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *jmode = json_object_object_get(yprod_json, "mode");
^
../ykpers-json.c:201:3: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *options = json_object_object_get(yprod_json, "options");
^
../ykpers-json.c:212:3: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
jtarget = json_object_object_get(yprod_json, "targetConfig");
^
../ykpers-json.c:243:4: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *jdigits = json_object_object_get(options, "oathDigits");
^
../ykpers-json.c:244:4: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *jrandom = json_object_object_get(options, "randomSeed");
^
../ykpers-json.c:259:6: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *jseed = json_object_object_get(options, "fixedSeedvalue");
^
../ykpers-json.c:281:5: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *joption = json_object_object_get(options, p->json_text);
^
../ykpers-json.c:296:5: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *joption = json_object_object_get(options, p->json_text);
^
../ykpers-json.c:311:5: warning: 'json_object_object_get' is deprecated (declared at /usr/include/json-c/json_object.h:271) [-Wdeprecated-declarations]
json_object *joption = json_object_object_get(options, p->json_text);
^

-Wall issue in ykpers.h

Can the comment on this line please be moved down below the #endif and put in a proper C89 /* */ comment instead of a C++/C99 // comment?

/usr/include/ykpers-1/ykpers.h:108:8: warning: extra tokens at end of #endif directive [enabled by default]

ibttr44CUeddgbtfudvfgluvluituhktlvgin

Personalisation tool should allow proprietary URIs in NDEF payloads

Hi

I want to program our yubikey neos with the following URI
'anyconnect://connect/?host=vpn.example.com&prefill_secondary_password='
This should allow me to use the yubikey neo with the cisco anyconnect client in a user friendly way.

But the tool won't allow URIs beginning with anything other than http, https, ftp etc.
I've looked at the document nfcforum-ts-rtd-uri-1.0.pdf mentioned in ykpers.c and proprietary URIs should be fine (See example A.3 'Storing a Proprietary URI on the Tag')

Kind Regards,
Alex

a2x dependency

When trying to build on a fresh install on linux make check install fails with WARNING: 'a2x' is missing on your system.

Installing asciidoc fixes the issue. Update the readme with that information?

USB error: could not claim interface 0: Operation not permitted

Setup: same as described in issue #14, but with Yubikey device selected in Vbox's device menu.

$ lsusb
Bus 001 Device 003: ID 1050:0010 Yubico.com Yubikey
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

$ dmesg|grep Yubi
[ 2.461538] usb 1-2: Product: Yubico Yubikey II
[ 2.461542] usb 1-2: Manufacturer: Yubico
[ 2.792249] input: Yubico Yubico Yubikey II as /devices/pci0000:00/0000:00:06.0/usb1/1-2/1-2:1.0/input/input3
[ 2.792357] generic-usb 0003:1050:0010.0002: input,hidraw1: USB HID v1.11 Keyboard [Yubico Yubico Yubikey II] on usb-0000:00:06.0-2/input0

$ ./ykchalresp 123456
USB error: could not claim interface 0: Operation not permitted

As this appears to be a permission problem, I tried running this as root:
$ sudo ./ykchalresp 123456
USB error: error sending control message: Connection timed out

In addition, the following appeared in dmesg:
[ 975.041413] usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd lt-ykchalresp rqt 161 rq 1 len 8 ret -110

strace on the last command gives some info that might be relevant:
open("/dev/bus/usb/001/003", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0x7fffe67ca120) = -1 ENOTTY (Inappropriate ioctl for device)
close(3) = 0
open("/dev/bus/usb/001/002", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0x7fffe67ca120) = -1 ENOTTY (Inappropriate ioctl for device)
close(3) = 0
open("/dev/bus/usb/001/001", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0x7fffe67ca120) = 9
close(3) = 0
open("/dev/bus/usb/001/003", O_RDWR) = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0x7fffe67ca170) = -1 ENODATA (No data available)
ioctl(3, USBDEVFS_CLAIMINTERFACE, 0x7fffe67ca0ec) = 0
ioctl(3, USBDEVFS_CONTROL or USBDEVFS_CONTROL32, 0x7fffe67ca0d0) = -1 ETIMEDOUT (Connection timed out)
ioctl(3, USBDEVFS_RELEASEINTERFACE, 0x7fffe67ca0ec) = 0
close(3) = 0
write(2, "USB error: error sending control"..., 63USB error: error sending control message: Connection timed out
) = 63

I've tried the workaround described in USB-Hid-Issue.asciidoc to no avail.

Please advise.

Universal build of libykpers for Mac

Hi,

Could you provide universal build of libykpers for Mac?
Example when using Keepass 2 with KeeChallenge plugin you need to have 32bit version of the libykpers, because Mono is 32bit and can't handle 64bit build.

More detailed description is over here: http://forum.yubico.com/viewtopic.php?f=12&t=1572

automake on CentOS 6.6

Building on CentOS 6.6 fails because of automake-1.11.1. The version number should be reduced to 1.11.1 inside configure.ac, instead of 1.11.3

diff --git a/configure.ac b/configure.ac
index a8063ae..bd798e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,7 +40,7 @@ AC_SUBST(LT_CURRENT, 18)
 AC_SUBST(LT_REVISION, 1)
 AC_SUBST(LT_AGE, 17)

-AM_INIT_AUTOMAKE([1.11.3 -Wall -Werror])
+AM_INIT_AUTOMAKE([1.11.1 -Wall -Werror])
 AM_SILENT_RULES([yes])
 AC_PROG_CC

Yubikey doesn't work with a USB 3 hub

My Yubikey doesn't work with a USB 3 hub - The light on the key doesn't turn on and I can't login to the https://demo.yubico.com. It's working when I connect the key directly to a USB port. I tested it on Mac and Ubuntu.

I wasn't sure if that's the correct github repository. Let me know if there is a better place to ask that. thanks!

pkg-config issues

I'm not that familiar with pkg-config but I'm seeing some unexpected behavior.

On OpenBSD libykpers-1 gets built with -pthread and linked against the threading impl but neither:

pkg-config --libs ykpers-1;
pkg-config --libs-only-other ykpers-1;

Lists -pthread as an LDFLAG.

On most systems this dep seems to get resolved correctly anyways by the linker, but it doesn't on others.

griehb

ykpersonalize -x fails on neo-n's with yubico cloud in slot 1 and oath-hotp in slot 2

I'm observing the following behavior on fresh Neo-N's. I'm on a Mac (Mavericks) with ykpersonalize installed via brew.

This fails:

ykpersonalize -2 -ooath-hotp -ooath-hotp8 -oappend-cr
ykpersonalize -x

With error Yubikey core error: write error

However, this works fine.

ykpersonalize -2 -z # clear out the second slot from the above step
ykpersonalize -x
ykpersonalize -1 -ooath-hotp -ooath-hotp8 -oappend-cr

new U2F security key is missing linux udev rules

I think 69-yubikey.rules and 70-yubikey.rules needs the "0120" device ID.

lsusb -v -d 1050:0120

Bus 005 Device 003: ID 1050:0120 Yubico.com
Device Descriptor:
...
idVendor 0x1050 Yubico.com
idProduct 0x0120
bcdDevice 3.33
iManufacturer 1 Yubico
iProduct 2 Security Key by Yubico
...

autoreconf --install fails

% uname -sr
SunOS 5.11
% autoreconf --install
/usr/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB
/usr/share/aclocal/aalib.m4:12: run info '(automake)Extending aclocal'
/usr/share/aclocal/aalib.m4:12: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
/usr/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB
/usr/share/aclocal/aalib.m4:12: run info '(automake)Extending aclocal'
/usr/share/aclocal/aalib.m4:12: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
Makefile.am:54: variable 'EXTRA_libykpers_1_la_DEPENDENCIES' is defined but no program or
Makefile.am:54: library has 'EXTRA_libykpers_1_la' as canonical name (possible typo)
autoreconf: /usr/bin/automake failed with exit status: 1
% automake --version
automake (GNU automake) 1.11.2

Looks like Issues #20 and #22 but automake claims to be the version required.

Move manpages to asciidoc

and use something like:
$ a2x --format=manpage

to convert it to a manpage when building.

add udev rules for YubiKey NEO

The current udev rules are for YubiKey 2 only (product id 0010), we should add udev rules for YubiKey NEO as well (product id 0110 and 0111).

Should udev rules `killall -9 scdaemon` for NEO?

For the Yubikey NEO, when used as a smart card, if you are using the current Yubico udev rules, when you remove the NEO then reinsert, smart card operations that use scdaemon stop working. When reinserting the NEO, scdaemon operations will still not function properly until scdaemon is restarted. One way to restart scdaemon is with a killall -9 scdaemon. This problem isn't specific to the NEO, it happens for any openpgp smart card, as far as I can tell.

The udev rules could do this for the user by simply adding RUN+="/usr/bin/killall -9 scdaemon". I'm not sure of the security implications of this. Are there any?

Would this be a worthwhile change? Or, because it only applies to NEO and not other Yubikeys, should the udev rule break out NEO and treat it differently?

I've tested the following udev rule on Arch Linux and it works, fixing the need to manually run killall -9 scdaemon:

ACTION!="add|change", GOTO="yubico_end"

# Udev rules for letting the console user access the Yubikey USB
# device node, needed for challenge/response to work correctly.

# Yubico Yubikey II
ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0010|0110|0111", \
    ENV{ID_SECURITY_TOKEN}="1", RUN+="/usr/bin/killall -9 scdaemon"

LABEL="yubico_end"

If it's felt this would be useful, I can make the changes and send a pull request.

ykpersonalize -fycfg -sfile is not storing AES key, private user id, ...

manual says:
-sfile save configuration to file instead of key. (if file is -, send to stdout)
-ifile read configuration from file. (if file is -, read from stdin)

from this, i thought that the file will contain all information, including:

• AES secret key
• access code
• public identity
• private identity

I would like to be able to use this file to personalize my yubikey and few seconds later to use it again to import values into authentication manager DB (i am using ubiserver now) and securely backup it...

While having this file with generic options is sweet, i think having definitive slot description would be even more useful... i would let user to redefine options on commandline, but take defaults from the file.
If we should keep this file only for generic options, it should be better described in manual as such. it definitely creates impression that everything will be saved there. From reading manual, I imagined this to work somewhat like dd or sfdisk does.

timing problems

Hello everyone!

This drove me crazy for some time... I use pam_yubico to authenticate. Every now and then authentication fails. Enabling debug messages I get this:

[pam_yubico.c:parse_cfg(738)] called.
[pam_yubico.c:parse_cfg(739)] flags 0 argc 2
[pam_yubico.c:parse_cfg(741)] argv[0]=mode=challenge-response
[pam_yubico.c:parse_cfg(741)] argv[1]=debug
[pam_yubico.c:parse_cfg(742)] id=-1
[pam_yubico.c:parse_cfg(743)] key=(null)
[pam_yubico.c:parse_cfg(744)] debug=1
[pam_yubico.c:parse_cfg(745)] alwaysok=0
[pam_yubico.c:parse_cfg(746)] verbose_otp=0
[pam_yubico.c:parse_cfg(747)] try_first_pass=0
[pam_yubico.c:parse_cfg(748)] use_first_pass=0
[pam_yubico.c:parse_cfg(749)] authfile=(null)
[pam_yubico.c:parse_cfg(750)] ldapserver=(null)
[pam_yubico.c:parse_cfg(751)] ldap_uri=(null)
[pam_yubico.c:parse_cfg(752)] ldapdn=(null)
[pam_yubico.c:parse_cfg(753)] user_attr=(null)
[pam_yubico.c:parse_cfg(754)] yubi_attr=(null)
[pam_yubico.c:parse_cfg(755)] yubi_attr_prefix=(null)
[pam_yubico.c:parse_cfg(756)] url=(null)
[pam_yubico.c:parse_cfg(757)] capath=(null)
[pam_yubico.c:parse_cfg(758)] token_id_length=12
[pam_yubico.c:parse_cfg(759)] mode=chresp
[pam_yubico.c:parse_cfg(760)] chalresp_path=(null)
[pam_yubico.c:pam_sm_authenticate(799)] get user returned: root
[util.c:get_user_challenge_file(218)] Failed to read serial number (serial-api-visible disabled?).
[pam_yubico.c:do_challenge_response(495)] Loading challenge from file /root/.yubico/challenge
[pam_yubico.c:do_challenge_response(511)] Cannot open file: /root/.yubico/challenge (No such file or directory)
[pam_yubico.c:do_challenge_response(657)] Yubikey core error: timeout
[pam_yubico.c:do_challenge_response(666)] Challenge response failed: No such file or directory

I wrote some example code, you can grab it here:
http://www.eworm.de/download/linux/yk_test.c

Just compile with:
$ gcc -o yk_test yk_test.c -lykpers-1

Then run it:
$ ./yk_test
Serial number: 1234567 (0)
Serial number: 1234567 (1)
[...]
Serial number: 1234567 (36)
yk_get_serial failed

This runs in loop just reading and printing the serial number. Last number is just a counter.

Adding a usleep(10) in _ykusb_write() "fixes" the issue for me. Ok, it's more of a workaround:
http://www.eworm.de/download/linux/yk_usleep.c

This should not be necessary and I have no idea why it happens. Looks like this is a race condition that only happens on fast systems (i7 Ivy Bridge here). Additionally a Yubikey Neo does not suffer the problem.

Any ideas?

Cheap Salt?

yubikey-personalization/ykpers.c

Line 352 in 6f669f5

/* There was no randomness files, so create a cheap

Salting from time seems like a questionable activity. Is there any known scenario where this is called into?

Yubikey core error: expected only one YubiKey but several present

When running ykinfo -a I am getting the error in the title of the ticket.

I just received a yubikey nano, and accidentally plugged it in while my other yubikey neo was connected.

Now neither the command line or GUI version of the tool want to work. It does not matter whether I have only 1 key connected, or if I switch between the two (one a time). Neither tool will work.

cannot get serial number with "ykinfo -s": "Yubikey core error: timeout"

I am unable to get the serial number using the ykinfo command. The '-s' option timesout.

$ sudo ykinfo -s
Yubikey core error: timeout

The other options return valid information and I am able to program the key using ykpersonalize.

$ sudo ykinfo -v
version: 2.3.1
$ sudo ykinfo -p
programming_sequence: 3
$ sudo ykinfo -t
touch_level: 1795

I'm running arch linux. Here are the versions of the yubikey tools that I have installed.

$ uname -a
Linux linuxbox 3.6-pf #1 SMP PREEMPT Sat Dec 1 01:20:09 EST 2012 x86_64 GNU/Linux

$ yaourt -Qs yubi
local/libyubikey 1.10-1
    Yubico C low-level library
local/yubico-c-client-git 2.9.33.ge7628d3-1
    Yubico yubikey client C library
local/yubikey-personalization-git 1.12.0.12.g5016c3c-1
    Yubico yubikey personalization library

Every time I run 'ykinfo -s' I see a new pair of entries in dmesg:

[13677.343780] input: Yubico Yubico Yubikey II as /devices/pci0000:00/0000:00:1d.7/usb4/4-1/4-1.1/4-1.1.2/4-1.1.2:1.0/input/input114
[13677.343985] hid-generic 0003:1050:0010.000F: input,hidraw4: USB HID v1.11 Keyboard [Yubico Yubico Yubikey II] on usb-0000:00:1d.7-1.1.2/input0

I have tried unbinding the device first from usbhid (and hid_generic) with:

$ sudo sh -c "echo 4-1.1.2:1.0 > /sys/module/usbhid/drivers/usb:usbhid/unbind"

this doesn't seem to have any effect for me.

Running 'ykinfo -s' through strace produces the following output:

...
nanosleep({0, 160000000}, NULL)         = 0
ioctl(6, USBDEVFS_CLAIMINTERFACE, 0x7fffcb1d30fc) = 0
timerfd_settime(5, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={14653, 118155000}}, NULL) = 0
ioctl(6, USBDEVFS_SUBMITURB or USBDEVFS_SUBMITURB32, 0x15bf9c0) = 0
poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLOUT}], 3, 60000) = 1 ([{fd=6, revents=POLLOUT}])
ioctl(6, USBDEVFS_REAPURBNDELAY or USBDEVFS_REAPURBNDELAY32, 0x7fffcb1d2ff8) = 0
timerfd_settime(5, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
ioctl(6, SNDRV_CTL_IOCTL_ELEM_LIST or USBDEVFS_RELEASEINTERFACE, 0x7fffcb1d30fc) = 0
nanosleep({0, 320000000}, NULL)         = 0
ioctl(6, USBDEVFS_CLAIMINTERFACE, 0x7fffcb1d30fc) = 0
timerfd_settime(5, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={14653, 440131000}}, NULL) = 0
ioctl(6, USBDEVFS_SUBMITURB or USBDEVFS_SUBMITURB32, 0x15bf9c0) = 0
poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLOUT}], 3, 60000) = 1 ([{fd=6, revents=POLLOUT}])
ioctl(6, USBDEVFS_REAPURBNDELAY or USBDEVFS_REAPURBNDELAY32, 0x7fffcb1d2ff8) = 0
timerfd_settime(5, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
ioctl(6, SNDRV_CTL_IOCTL_ELEM_LIST or USBDEVFS_RELEASEINTERFACE, 0x7fffcb1d30fc) = 0
nanosleep({0, 500000000}, NULL)         = 0
write(2, "Yubikey core error: timeout\n", 28Yubikey core error: timeout
) = 28
ioctl(6, SNDRV_CTL_IOCTL_ELEM_READ or USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0x7fffcb1d3290) = 1
write(4, "\1", 1)                       = 1
read(3, "\1", 1)                        = 1
close(6)                                = 0
close(3)                                = 0
close(4)                                = 0
close(5)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

ykchalresp: get challange from env variable

Reading a secure challenge from command line arguments isn't safe, because other users and processes are able to read them. Environment variables are considered to be safe on most Linux systems. So it would be great if ykchalresp would be able to read a challenge from an environment variable (e.g. YKCHAL) instead.

Support multi-programming

There should be a (possibly separate) tool to program multiple yubikeys at the same time. It could work by reading some input file with multiple configuration/keys/serials and when yubikeys are inserted it will personalize them. It should support having multiple yubikeys inserted at the same time.

/Simon

Grammar issue in man pages

The man pages repeatedly use the word "it's" when what is meant is "its" on at least lines 303, 306, and 309 of the source file.

build binaries for mac

-

Security key not detected on OS X 10.11

I recently got a yubikey through the GitHub promotion, but it's not being detected. After doing some digging I discovered that the device is simply not supported in ykcore.

Device info:

  Product ID:   0x0120
  Vendor ID:    0x1050
  Version:  4.18
  Speed:    Up to 12 Mb/sec
  Manufacturer: Yubico
  Location ID:  0x14200000 / 9
  Current Available (mA):   1000
  Current Required (mA):    30
  Extra Operating Current (mA): 0

I was able to get the tool to actually attempt to do something with it by adding 0x0120 to the pids in yk_open_first_key and removing the checks on usage and usagePage in _ykusb_open_device located in ykcore_osx.c.

I added some debug statements to the process:

diff --git a/ykcore/ykcore.c b/ykcore/ykcore.c
index 2dfad42..19b9399 100644
--- a/ykcore/ykcore.c
+++ b/ykcore/ykcore.c
@@ -67,7 +67,7 @@ int yk_release(void)

 YK_KEY *yk_open_first_key(void)
 {
-       int pids[] = {YUBIKEY_PID, NEO_OTP_PID, NEO_OTP_CCID_PID,
+       int pids[] = {YUBIKEY_PID, 0x0120, NEO_OTP_PID, NEO_OTP_CCID_PID,
                NEO_OTP_U2F_PID, NEO_OTP_U2F_CCID_PID, YK4_OTP_PID,
                YK4_OTP_U2F_PID, YK4_OTP_CCID_PID, YK4_OTP_U2F_CCID_PID,
                PLUS_U2F_OTP_PID};
diff --git a/ykcore/ykcore_osx.c b/ykcore/ykcore_osx.c
index a07b8d8..7521581 100644
--- a/ykcore/ykcore_osx.c
+++ b/ykcore/ykcore_osx.c
@@ -105,11 +105,15 @@ void *_ykusb_open_device(int vendor_id, int *product_ids, size_t pids_len)
                        long usagePage = _ykosx_getIntProperty( dev, CFSTR( kIOHIDPrimaryUsagePageKey ));
                        long usage = _ykosx_getIntProperty( dev, CFSTR( kIOHIDPrimaryUsageKey ));
                        long devVendorId = _ykosx_getIntProperty( dev, CFSTR( kIOHIDVendorIDKey ));
+
+                       printf("%lx, %lx, %lx\n", usagePage, usage, devVendorId);
                        /* usagePage 1 is generic desktop and usage 6 is keyboard */
-                       if(usagePage == 1 && usage == 6 && devVendorId == vendor_id) {
+                       if( devVendorId == vendor_id) {
                                long devProductId = _ykosx_getIntProperty( dev, CFSTR( kIOHIDProductIDKey ));
                                size_t j;
                                for(j = 0; j < pids_len; j++) {
+                                       printf("product id: %d, target: %ld\n", product_ids[j], devProductId);
+
                                        if(product_ids[j] == devProductId) {
                                                if(yk == NULL) {
                                                        yk = dev;

which spit out:

f1d0, 1, 1050
product id: 16, target: 288
product id: 288, target: 288
1, 2, 5ac
1, 2, 5ac
ff00, 1, 5ac
1, 6, 5ac
1, 2, 5ac
Firmware version 4.1.8 Touch level 256 Unconfigured
A slot must be chosen with -1 or -2.

I'm not sure what this is supposed to be, but I can see that by adding the product ID and removing the usagePage/usage requirements then this is device discovered.

Handle several YubiKeys gracefully

As the library works now only the first key found is reachable, and no indication is given that there are several keys in the computer.

Maybe yk_open_first_key() should return an error if several are found, and we could have a mechanism to enumerate keys and choose which to open.

ibttr

ykinfo: get serial doesn't work

OS X 10.9.5
MacBook Air
ykpers 1.16.0
YubiKey NEO firmware 3.2

Options -s, -m, -H, -a (anything that involves get serial) fails like this:

$ ./ykinfo -a
Yubikey core error: timeout

Other commands work okay.

$ ./ykinfo -v
version: 3.2.0

doxygen documentation

write doxygen (or similar) documentation for the public interfaces.

attempts to use previously saved config.legacy fails with obscure error message

Tested on debian sid and also with latest git code, having the same result.

This simple tests always leads to: "Yubikey personalization error: invalid option/argument value",
which is really not telling much.

$ ykpersonalize -1 -v -flegacy -sfile.legacy -a11111111111111111111111111111111 -o fixed=ccccbbbbcccc -o serial-api-visible ; cat file.legacy ; ykpersonalize -1 -v -flegacy -ifile.legacy
Firmware version 2.4.2 Touch level 2305 Program sequence 3
Serial number : 2222222

fixed: m:ccccbbbbcccc
uid: 000000000000
key: h:11111111111111111111111111111111
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags: 
extended_flags: SERIAL_API_VISIBLE
Firmware version 2.4.2 Touch level 2305 Program sequence 3
Serial number : 2222222

Yubikey personalization error: invalid option/argument value
$

Help text says NDEF2 rather than NDEF4.

The following should refer to NDEF type 4 rather than NDEF type 2

-nXXX.. Write NDEF type 2 URI to YubiKey NEO, must be used with -1 or -2
-tXXX.. Write NDEF type 2 text to YubiKey NEO, must be used with -1 or -2

Write a thin COM object wrapper

It would be nice to use the ykpers DLL functions as a COM object.

EXTRA_libykpers_1_la_DEPENDENCIES is defined but not used

Using automake 1.11.1 (present in Debian stable), automake/autoreconf fails with an error message:

...
Makefile.am: installing ./INSTALL' Makefile.am:52: variableEXTRA_libykpers_1_la_DEPENDENCIES' is defined but no program or
Makefile.am:52: library has `EXTRA_libykpers_1_la' as canonical name (possible typo)
autoreconf: automake failed with exit status: 1

Commenting out the dependencies line allows autoreconf to complete.

Docs missing?

Hi, the README file refers to documentation that's not in the repo. The doc link in the github project view links to a 404 page,

autoreconf fails

On our CentOS servers, the autoreconf --install fails.

configure.ac:54: warning: macro `AM_PROG_AR' not found in library
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: copying file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:54: warning: macro `AM_PROG_AR' not found in library
configure.ac:47: installing `build-aux/config.guess'
configure.ac:47: installing `build-aux/config.sub'
configure.ac:43: installing `build-aux/install-sh'
configure.ac:43: installing `build-aux/missing'
tests/Makefile.am: installing `build-aux/depcomp'
Makefile.am: installing `./INSTALL'
Makefile.am:54: variable `EXTRA_libykpers_1_la_DEPENDENCIES' is defined but no program or
Makefile.am:54: library has `EXTRA_libykpers_1_la' as canonical name (possible typo)
autoreconf: automake failed with exit status: 1

I haven't tried to pinpoint it yet, but fd4d73e works.

Environment:

# autoreconf --version
autoreconf (GNU Autoconf) 2.63
# uname -a
Linux  2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/redhat-release 
CentOS release 6.3 (Final)

Can't read serial from my GitHub U2F Yubikey

Fedora 23:

$ ykinfo -m
Yubikey core error: timeout

Other tools fail as well:

$ ykpamcfg 
[util.c:get_user_challenge_file(302)] Failed to read serial number (serial-api-visible disabled?).
Yubikey core error: timeout

Using ykpers-1.17.2. Is that supposed to work with these keys? It seems to work fine for my friends.

Yubikey core error: no yubikey present (OSX El Capitan)

Hi,
I just got my Yubikey 4 nano, it's works great with dropbox/ google etc. I configured it as smart-card (for open gpg), and tried to enable OTP, but I can't do that.
I grabbed ykpers-1.17.2-mac and tried to run:

% ./ykinfo -a
Yubikey core error: no yubikey present
% sudo ./ykinfo -a
Password:
Yubikey core error: no yubikey present

but Yubikey is working as charm in every other software (PIV, Authenticator, and from console with gpg --card-status)
What can I do with that? I should install something more? Maybe there are some drivers?

When I plug in my key I have something like that in my logs:

11/20/15 8:45:11.000 PM kernel[0]: considerRebuildOfPrelinkedKernel prebuild rebuild has expired
11/20/15 8:45:11.000 PM kernel[0]: com_driver_GxxxDriver::probe fails
11/20/15 8:45:11.000 PM kernel[0]: com_driver_GxxxDriver::probe fails
11/20/15 8:45:12.394 PM com.apple.SecurityServer[83]: Token reader Yubico Yubikey 4 U2F+CCID inserted into system
11/20/15 8:45:12.394 PM com.apple.SecurityServer[83]: reader Yubico Yubikey 4 U2F+CCID: state changed 0 -> 34
11/20/15 8:45:12.394 PM com.apple.SecurityServer[83]: token in reader Yubico Yubikey 4 U2F+CCID cannot be used (error 229)

Yubikey core error: no yubikey present

Synopsis: ykchalresp gives above error with Yubikey present

Environment:
VirtualBox 4.1.18 under Windows7 64bit host (Yubikey listed as a USB device "Yubico Yuikey II [0224]"
Debian 6.0.5
arch i686
kernel 2.6.32-5-686
Yubikey-personalization 1.7.1 (cloned from git 2012-08-12)
Yubikey Firmware version 2.2.4

Pressing Yubikey results in text being displayed on terminal.

$ ./ykchalresp -v -2 123456
Yubikey core error: no yubikey present

Running command as root gave same error.

$ lsusb
Bus 002 Device 003: ID 80ee:0021 VirtualBox USB Tablet
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmesg and /var/log/* showed nothing related to USB or Yubi*.

Any ideas? Let me know if you need more info.

Thanks,

Rony

warning on const qualifiers

Hi...

this is not an issue... but as I always got this annoying warning...

In file included from /usr/include/ykpers-1/ykstatus.h:35,
from /usr/include/ykpers-1/ykpers.h:36,
...
/usr/include/ykpers-1/ykcore.h:122: warning: type qualifiers ignored on function return type
/usr/include/ykpers-1/ykpers.h:109: warning: type qualifiers ignored on function return type

is there a reason to have CONST qualifiers in functions:

extern int * const _yk_errno_location(void);
extern int * const _ykp_errno_location(void);

???

best regards

       GP

Need a way to make sure ykperrno gets freed.

Multiple calls to functions that init ykperrno currently leave 4 bytes per call allocated.

Example valgrind output:

$ sudo valgrind --leak-check=full --show-reachable=yes ykchalresp -2 'aoeu'
==15559== Memcheck, a memory error detector
==15559== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15559== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==15559== Command: ykchalresp -2 aoeu
==15559==
[response removed]
==15559==
==15559== HEAP SUMMARY:
==15559== in use at exit: 8 bytes in 2 blocks
==15559== total heap usage: 117 allocs, 115 frees, 86,391 bytes allocated
==15559==
==15559== 4 bytes in 1 blocks are still reachable in loss record 1 of 2
==15559== at 0x4C25E84: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x4E30C8E: _ykp_errno_location (in /usr/lib/libykpers-1.so.1.4.0)
==15559== by 0x4017CE: ??? (in /usr/bin/ykchalresp)
==15559== by 0x5889EAC: (below main) (libc-start.c:228)
==15559==
==15559== 4 bytes in 1 blocks are still reachable in loss record 2 of 2
==15559== at 0x4C25E84: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15559== by 0x4E3396E: _yk_errno_location (in /usr/lib/libykpers-1.so.1.4.0)
==15559== by 0x4017D9: ??? (in /usr/bin/ykchalresp)
==15559== by 0x5889EAC: (below main) (libc-start.c:228)
==15559==
==15559== LEAK SUMMARY:
==15559== definitely lost: 0 bytes in 0 blocks
==15559== indirectly lost: 0 bytes in 0 blocks
==15559== possibly lost: 0 bytes in 0 blocks
==15559== still reachable: 8 bytes in 2 blocks
==15559== suppressed: 0 bytes in 0 blocks
==15559==
==15559== For counts of detected and suppressed errors, rerun with: -v
==15559== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

CHAL_BTN_TRIG has no effect

Not sure if this is the right place for this report, please correct me if it's not.

I've got a Neo, with Firmware version 3.0.4. I am trying to set up challenge-response pam authentication. I noticed that regardless is whether I run

ykpersonalize -2 -o chal-resp ... -o chal-btn-trig

or

ykpersonalize -2 -o chal-resp ... -o -chal-btn-trig

subsequent

ykchalresp -v -2 ...

returns result instantly, without making the LED blink and without waiting for me to touch the sensor. If it matters, the mode is set to 82.

Is it a bug, undocumented (mis)feature?

refactor and clean up code

Either clean up the command line tool or redesign the library API, so the package becomes more maintainable and understandable. Top priority is to improve the command line parsing of the tool.

Allow piping input for `ykchalresp`

It would be nice to be able to pipe the challenge into ykchalresp.

cat ~/some_file_with_secret | ykchalresp

mac problems

There seems to be problems using the library and tools on mac, most of these issues seem to be on 10.7.
This might be a permissions issue and work better as root.