Yubico Forum

Any chance that alternative layouts will be supported in a near-future firmware release? Some of our users use the Dvorak keyboard layout and are forced to switch back and forth between Qwerty and Dvorak to utilize their Yubikey's....far from an ideal user experience.

We've got the "Dvorak question" quite a few times over the last year and it seems like we have to do anything about it.

One approach is to add a backend solution to it, where the backend makes some kind of guesswork if the OTP does not look like expected or if the authentication fails.

Another one is of course to add a configurable option to change the key to a Dvorak layout. However - how would we protect this setting from being changed by a potential saboteur ? Assume organization X issuing a set of Yubikeys to a large number of users where some have Dvorak keyboards. If we would make a "Dvorak flag" being pubilic - what if a saboteur would flip this flag ? As the issuer can't protect it, what would be the way to go ?

A third option is of course to make a special "Dvorak version" available. I'm perfectly fine with that, but from a logistical perspective it seems less favorable.

Please let me know your thoughts here. We're somewhat open to all three options.

Regards,

JakobE
Hardware- and firmware guy @ Yubico

Given the multitude of keyboard layouts in use worldwide, I think that the only realistic option is to handle it serverside. As you discussed, any client-side hints open up new vulnerabilities, and special firmware sounds like an administrative nightmare. It seems like letting the SSO admin specify the accepted fall-through types for the sieve would likely alleviate any hassles.

I agree with heisenberg. To be honest i didn't knew anything about the Dvorak keyboard layout
So I checked out wikipedia. I'd like to build-in this feature into my OTP validation server.
Did someone already defined the needed "modhex"-similar mapping table?

My vote goes to the serverside. IMO the firmware already has too many features as it is.

While at it: may I suggest we have the option to install hardened firmware - that is: firmware that does not have all the options like capslock double-clicking, surfing to an URL etc.?

The bytes freed might be used to store a new function; one to offer better protection against malicious re-programming of the key. I suggest having the key send a string of random bytes if it receives a 'programming request'. These bytes need to be encrypted by the programming process using the key's current AES secret. The programming proces subsequently sents the encrypted string back to the key. Only if the key can decrypt the message, programming is allowed (including updating of the AES string etc.). Also, the key should cease to function for a minute if an unsuccesfull attempt was made to program it while blinking the ring in a fast pace. On the second try, the key should double the time it ceases functioning etc. [not sure if unplugging would have to stop the cycle or restart it; from a security perspective I'd say 'restart it'].

Will put this idea on the ideas page later, if someone wants to discuss it, we may need to start a new thread.

The cool way to support alternate keyboard layouts would be to parse the os's keyboard mappings database, look up the yubikey's keycodes for each one, and then you'd have a comprehensive decoder ring. I did that.

People who use dvorak are already used to changing their keymap before they enter their password (e.g. for the YK2 long password mode). But if an attacker changed a future YK's keymap it would simply be wrong all the time, the user would probably be confused.

I wrote a little program that changes the keyboard layout and asks X11 for the keycode -> character mapping. Here are the results for a few layouts. The code is a Python dictionary of {[unicode characters,] : [layouts,]} that would be easy to incorporate into a more sophisticated modhex decoder.

ؤﻻيثبلاهتنمىقفعر ['ar']
cbdefghıjklnrtuv ['tr']
ъфаеожгстнвхишкэ ['bg']
jxe.uidchtnbpygk ['dvorak']
сивуапршолдткегм ['ru', 'uz']
cbdefghijklnrtuv ['be', 'fr', 'dk', 'hr', 'jp', 'de', 'sk', 'it', 'cz', 'en_US', 'br', 'us_intl', 'es', 'cz_qwerty', 'pt', 'no', 'lt', 'us', 'lv', 'mt', 'fr-latin9', 'ro', 'pl', 'gb']
цбдефгхијклнртув ['mk']
ܤܧܝܖܒܠܐܗܬܢܡ܀ܩܦܥܪ ['syr']
แกำดเราสพะอ ['th']

More layouts! I went ahead and wrote some JavaScript to translate the input from 400+ keyboard layouts to modhex. This ought to go into the server. The server should check more than one modhex interpretation of the otp in the rare case that's necessary.

Try it at http://dingoskidneys.com/~dholth/yubikey/

dholth, thanks for your work here. I agree that the best is to integrate support for this in the validation server. Before I spend too much time on this, maybe I can learn from what you have done. For example, is it possible to write a function that takes a string and returns a "guessed" correct string by doing only string operations? That would be the easiest to implement in the validation server.

Alas, I suspect the function needs to use the database as an "oracle" into whether a particular guessed OTP is OK or not, and then iterate through all the guesses it have, before deciding which is the best guess. This is also possible to implement, but more work.

Anyway, I'd like to invite you to look at the validation server code, to see if you can find a place to add this code conversion. Check out the project and source code at:

http://code.google.com/p/yubikey-val-server-php/

In particular:
http://code.google.com/p/yubikey-val-se ... verify.php
http://code.google.com/p/yubikey-val-se ... common.php

After testing, this is something we definitely would consider deploying on our main servers. It looks feasible to me.

/Simon

I had sincerely hoped to avoid doing any Unicode coding in PHP, but porting the JavaScript OTP decoder (see demo web page) to PHP (and Java, and Python, ...) should be straightforward.

http://dingoskidneys.com/cgi-bin/hgwebdir.cgi/yubikey/ is the source code. You can install Mercurial and do an "hg clone" on this url to get a local copy with full history.

If you play with the demo page at http://dingoskidneys.com/~dholth/yubikey/ you will see that in almost every case there will be only one possible interpretation of an OTP. As long as all 16 characters appear in an OTP (for the supported layouts), there will always be only one way to interpret it except in certain Armenian layouts where there will always be 2 ways to interpret the OTP. That gets you pretty far without having to check 2 OTPs in one request.