Yubico Forum https://forum.yubico.com/ |
|
[SOLVED] HMAC-SHA1 quirks https://forum.yubico.com/viewtopic.php?f=16&t=1078 |
Page 1 of 1 |
Author: | edutko [ Mon Jun 03, 2013 3:37 am ] |
Post subject: | [SOLVED] HMAC-SHA1 quirks |
I am attempting to write some code that emulates the HMAC-SHA1 challege-response mechanism in my YubiKey so that I can use YubiKey-secured Password Safe safes on my iPhone. (For more background, see my project post in the community projects section.) I noticed that there are a few quirks with the HMAC-SHA1 implementation on the YubiKey. So far, all but one involves some amount of truncation of the challenge prior to calculation of the HMAC. I think I've managed to find most of them, but I'm not certain that I've found all of them. Is it possible to get some documentation on how the YubiKey prepares the data before calculating the HMAC? Here are the cases I've found so far. All of these apply after truncating the challenge to 64 bytes and before the HMAC is calculated.
FYI, I'm using the YkLib22 code to send the challenge and retrieve the response from the YubiKey, and I've checked in the debugger to be sure that any manipulation of the challenge happens in the YubiKey, not in this code. Thanks in advance for any guidance. |
Author: | edutko [ Fri Jun 07, 2013 1:26 am ] |
Post subject: | Re: [QUESTION] HMAC-SHA1 quirks |
Update: After improving my testing methodology, I was able to run through several more tests with more targeted challenges. I'm not 100% certain that I've hit all of the cases yet, but I can say with fairly high confidence that the algorithm below will cover most - if not all - cases. Based on my latest tests, the algorithm appears to be: 1. If the challenge is greater than 64 bytes long, truncate it to 64 bytes. (This is actually done in YkLib; I have not checked whether the hardware performs the same truncation if passed a longer challenge.) 2. Prepare the challenge:
I'd still be interested to hear from the Yubico engineers on this. Are there any corner cases I've missed? Is this behavior by design? Can I expect it to be consistent across all types of YubiKeys? |
Author: | Tom [ Wed Jun 12, 2013 10:37 am ] |
Post subject: | Re: [QUESTION] HMAC-SHA1 quirks |
1. Input is limited to 64 bytes maximum. The processor is very slow (1 block takes about 50 ms) and the challenge-response mechanism is also slow (low speed USB using reports). Furthermore, the input buffer is exactly 64 bytes so implementing an arbitrary mechanism would be difficult and awkward. 2. As there is no byte count field in the "original" Yubikey USB protocol, there is a bit of a quirk to determine the length of dynamic input. There is a somewhat confusing (yet stringent) flag named CFGFLAG_HMAC_LT64, which determines if the input is dynamic (flag set) or if the input is exactly 64 bytes in length 3. Zero bytes is replaced with a binary '00' with length 1, which I think is sensible 4. If the LT64 flag is set (input is 0-63 bytes), the last byte in the input is used as a null token to calculate the length of the input. Assuming a "casual" use of the library, the last byte will be zero and therefore, the Yubikey will search backwards until the last non-zero byte is found. Best for a <64 bytes input is to set the byte following the last byte to the last byte inverted, i.e. buf[len] = ~buf[len -1], this assuming len != 0. Caveats: The standard Yubikey had a bug where the LT64 flag does not work correctly (assumed to be cleared). Fixed in 2.2.6 The NEO had a bug where this mechanism did not worked correctly. Fixed in 3.1.5. |
Author: | edutko [ Sat Jun 22, 2013 1:03 pm ] |
Post subject: | Re: [SOLVED] HMAC-SHA1 quirks |
Thanks for the detail, Tom. This is really helpful! |
Author: | Tom2 [ Wed Mar 04, 2015 10:46 am ] |
Post subject: | Re: [SOLVED] HMAC-SHA1 quirks |
https://github.com/Yubico/yubikey-perso ... chalresp.c |
Page 1 of 1 | All times are UTC + 1 hour |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |