Yubico Forum

Hi,

If you want to develop applications for the yubikey, you can use my simulator to avoid reprogramming your original hardware yubikey thereby rendering it useless to yubico's services.

Try my new yubikey simulator here:
http://zyz.dk/yk/generator_0.2/yubi_generator.php

You can find my sourcecode is here:
http://zyz.dk/yk/generator_0.2/yubi_generator.php.html

Best regards,
Alex

Thanks for that simulator.
i think there is a issue in the public id.
you type
i think you should not allow ascii but Hexa instead!

i think the public ID is 48 bit,
i may be wrong but just my 2 cent.


Got also a question, what is the generate OTP button for?

Thanks again for that nice simulator

_________________
Patgadget
Montreal

Hi patgadget,

Thanks for your comments on my emulator.

About the public ID I think you are right about the 48 bit hex. This is how the yubikeys are configured by default when you buy the hardware. The 48 bit is translated via yubico's modhex function to an ascii characterset containing these letters: "cbdefghijklnrtuv". But if you read the documentation from the personalization tools the definition of the publicID is a bit more loose:

3.3 Device public identity
The device could be assigned a static identity, which is a static binary string that is sent
in clear text to uniquely identify the device. The service validating an OTP string from a
device would typically extract this part to retrieve the appropriate encryption key for the
particular YubiKey in question.
The public identity has no meaning for the device itself and if used, the sequencing and
exact meaning of the public identity is defined by the device issuer.

As far as i know the public ID can be longer than 48 bits (12 modhex ascii characters). Thats why I made it an ascii-field with optional length.
Maybe the yubico-team can confirm that I am right or wrong on this part?

The generate OTP-button is used if you manually want to enter all of the values and generate the OTP. It doesn't autocount, set timer and randomnumber That might be usefull for some situations.

Best regards,
Alex

Hy,



i think that the yubikey can only use the 16 caracter set (b,c,d,e,f,....) and the first 12 caractere of the yubikey is the public ID. so 12 x 4bit = 48 bit. (i think)
Can a yubikey guy (or girl) give there opinion on that

your simulator still work perfectly even if you keep the ascii set.

Thanks to you i did not reprogram my yubikey yet, as i played a lot with the simultator.

_________________
Patgadget
Montreal

Hi Patgadget,

You are absolutely right about that the public ID can only contain the modhex 16-char set (because the programming tool saves the public ID in hex wich is later encoded with modhex).

I just did a programming of my yubikey and I can make the public ID longer than the standard 48 bit. I tried 96 bit (24 modhex characters) without any problems. I don't know where the limit is - I will leave that to the yubiteam to tell us

Best regards,
Alex

Hi,

I moved my project to here: https://yubisim.googlecode.com/
This is the place where I will keep it updated in the future.

Best regards,
Alex Jensen

Between simulator, decoder, and me getting my yubikey's AES key, I have learned a few things about reconfiguration. If a key ever does get used up fully, that is ALL 32767 Inserts, then you would have to reconfigure the key. I have indeed reconfigured mine, such that no one else can destroy any of the settings in my key now. You can only do this, so that it will still work on yubico server, if and ONLY if you know your AES key, as well as a few other important fields.

(And I do have a suggestion for the decoder. Decode the modhex public identifier, as well as show that identifier in all decode results.)

It is not enough to just go into the config tool, to set a password only. (Could we request that for the next firmware revision?). You must indeed configure everything else at once. This means you need to decode an existing passcode, to get the Secret ID, so that it can be set to that exact ID. You have to translate the first 12 characters of your existing OTP from modhex to hex, and set that as the public ID. If you are doing this, set Cur password as blank, if it has not been set before, and set new password to something that you WILL remember, or otherwise have written down some place secure. Set up the flags, so that everything is false except ykFLAK_APPEND_CR, and if you wish to allow capslock trigger, ykFLAG_ALLOW_HIDTRIG.

The other reason you need to decode an existing passcode, preferably a fresh one, is to see what your current counter is. You DO NOT want to be doing this configuration, with a high counter. The reason for that, is when you do configure a yubikey, the insert counter is reset back to 1. (which why you only have 32767 inserts.) Once that is done, follow these steps.

1. Open notepad, and make sure it is the focus of key stroke input.
2. Insert yubikey.
3. Press button, and wait for yubikey OTP to be typed. (This step is NOT optional. If you remove the yubikey before retrieving an OTP, the counter will NOT go up by one.)
4. Remove yubikey.
5. Lather.
6. Rinse.
7. Repeat Steps 2-7 until insert counter is back up to where it was. This means if your counter is up at 100, then you have to do this 100 times, or if it is up at 1000, then you have to do this 1000 times.

Cool !

The way our server works today is that it expects the (usageCounter || sessionCounter) to be > (last_verified_usageCounter || last_verified_sessionCounter). If the counter wraps, yes - you're toasted.

But, as discussed in another thread, it is extremely unlikely that this will ever happen, even at very extensive use. If you OTOH use the simulator as an automated / shared service for whatever reason, it might be a different thing.

The first question regarding the public id: It can be 0 to 16 bytes, i.e. 0 to 32 modhex characters. The default configuration for our keys is 6 bytes public id.

The second question:

It is not enough to just go into the config tool, to set a password only. (Could we request that for the next firmware revision?).

I did not fully understand that. Can you please go through that again ?

Regards,

JakobE
Hardware- and firmware guy @ Yubico

What I meant, is I would like for the possibility to prevent a destructive attack on any existing yubikey, without needing to actually set any of the other parameters, such as the AES key and the like, thereby in most normal cases preventing the yubikey from working on the yubico servers again. That is, if I didn't know my AES key, and there was no password protection on the configuration, then somebody could take my yubikey for a few minutes, perform a configuration on it, changing some of the parameters, and prevent my yubikey from working on the yubico servers again. It would be nice to be able to set JUST the configuration password, so that no one else can do a destruction attack on the key. (A simple destruction attack would be one thing, but a brick the yubikey destruction attack by also setting the password in the process would be even worse.)