I noticed that for ECC keys, it doesn't offset the target buffer pointer by 8 like the RSA implementation does (onlykey_flashget_label(ptr, (offset + i)) instead of onlykey_flashget_label(ptr+8, (offset + i))), but it does still use only the final 8 characters in the comparison case (keyid_match = memcmp (ptr+8, recv_buffer+6, 8);). Is this a mistake?

Hi,

I'm trying to figure out how OnlyKey handles counters for FIDO2 in a backup -> restore scenario. Currently I can only find code for Yubikey OTP slots:

This seems wrong to me. Using a counter value that is less than the last used counter value can invalidate the key at the origin. This would be explicitly problematic in the backup restore scenario. Let's say you have a primary key and a backup key (restored from a backup now or later). Now use the primary key for a half a year with multiple logins per day (not unusual). Then lose the primary key (happens) and consider yourself lucky you have a backup key. Attempt a login with your backup key. See how your backup key gets invalidated due to a negative counter diff. Now you are locked out, defeating the purpose of the backup.

A better solution (albeit far from perfect) would be to use a epoc timestamp on restore to ensure the counter is at least increasing. Granted some strict implementation would possibly flag the large counter increase. But, as there exists keys that share the counter on the key and also increase the counter by more than 1 to prevent data leakage, I'd expect that to be less of a problem versus a fixed 300 as most implementations do check for a decreased counter.

Other implementation have used fixed 0 counters in the past.

Trezor seems to implement both as well. Although this also seems to have it's problems it is at least configurable: trezor/trezor-firmware#537

What is the current implementation for counter restore for FIDO2 with an OnlyKey? And shouldn't we at least change the hardcoded 300?

Hi!

I noticed that wiping a RSA key only wipe the private part but not the type field. As a result, any subsequent use of the wiped key doesn't fail with Error no RSA Private Key set in this slot as expected. For example, wiping a RSA key and then sending a OKSIGN results in Error invalid key, key check failed.

When wiping an ECC key the type field is correctly set to 0, and every subsequent use of the key results in Error no ECC Private Key set in this slot.

Code involved

The code to patch, if the described behavior is indeed a bug, is located in okcore.cpp, in the rsa_priv_flash function:

I think there should be okeeprom_eeset_rsakey(0, (int)buffer[5]); inserted somewhere in this bloc.

I believe this check here fido2/ctap.cpp prevents a CTAP request from getting the number of pin retries left unless you also include the auth protocol version (1).

// This check happens before any command is allowed to proceed.
    if (CP.pinProtocol != 1 || CP.subCommand == 0)
    {
        return CTAP1_ERR_OTHER;
    }

According to the FIDO spec, the only required parameter is the SubCommand. Since this is an unauthenticated request, the pinProtocol is ignored.

For reference, when I make this request to a YubiKey, it returns the retries correctly.

I posted an updated version of this - that also pulls the processor unique 128 bit ID number.
https://forum.pjrc.com/threads/91-teensy-3-MAC-address?p=103646&viewfull=1#post103646

Only PJRC writes the serial/MAC bits as far as I know - not the bootloader - based on the one "non-TEENSY", 'teensy' I got.

I see that when reading RSA key labels, the buffer is: id, pipe character, 8 untouched bytes, 8 characters. I notice I consistently get 0xF3, 0x02, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00 in the first 8 bytes. What's the explanation behind this data? Is it simply junk due to the fact that the memory isn't wiped after being allocated?

I also noticed that onlykey_flashget_label always assumes there will be EElen_label (16) bytes to retrieve. Isn't this going to end up writing past the end of the buffer by 7 bytes in the RSA implementation?

uint8_t label[EElen_label+3];
uint8_t *ptr;
ptr=label+2;
onlykey_flashget_label(ptr+8, (offset + i));
// { ???                 } { uint8_t label[19]                                    }
// 1A,19,18,17,16,15,14,13,12,11,10,0F,0E,0D,0C,0B,0A,09,08,07,06,05,04,03,02,01,00
//  ^ptr+8+len                                      ^ptr+8                  ^ptr

I've configured TOTP in slot 1a. It initially works, but then if I unplug the OnlyKey, and plug it in again, unlock it with my PIN, when I attempt to use slot 1a, the TOTP code returned says "NOTSET".

Further to this, if I plug in the OnlyKey, unlock it with my PIN, then boot up the OnlyKey configuration application, the TOTP slot begins to work again. When I close the configuration program, the slot resumes outputting "NOTSET"

Does the password.h store the password in the Eeprom?

Hi!

I'm currently playing with PGP key signature and decryption using my OnlyKey. I dialogue directly with the key, sending the OKSIGN and OKDECRYPT messages over HID. While testing with a 4096 bits RSA key, signing gives a wrong signature:

Signatures with a 4096 bits RSA key should be 512 bytes long (8 HID packets). However I only get 448 bytes (7 HID packets). I think I understand why: the usb_rawhid_send2 function will send a packet only if there is less than 4 packets processed at the moment. If there is 4 packets currently processed, the function will "sleep" a little then try again until the packet can be sent or a timeout is reached. That's the problem: the send_transport_response function has to send 8 packets, but a timeout of 0 ms is specified (RawHID.send2(resp_buffer, 0);):

I guess the timeout is too short for the packet to be sent, thus the loss.

Increasing this timeout to 100 ms (as for FIDO) should be enough I think

Hi!

Just noticed, that your use of memset is inconsistent with its declaration (9 vs 8 bytes). I have not seen the whole code, but just in case it is a buffer overflow I am reporting it.

Would be great to be able to bind a button to a disconnect action. In this way i could lock the only key without disconnecting and connecting the key from the usb.