YubiKeyIdeas

From Yubico

Jump to: navigation, search

Contents

YubiKey Ideas

This page is meant as a brain storming place to hash out applications or services that does not yet exist. The reason to create this page were that we had a couple of submissions to the YubiKing Award that did not fit into any of the three categories: application, online service, or development tool. The proposed ideas are still worth consideration, and it would be unfortunate to lose track of them. Thus, we intend to collect them on this page.

If you wish to discuss some idea further, we recommend you to use the Yubico Forum rather than updating this page too frequently.

Hardened firmware

AUTHOR

--Fortean 07:27, 24 June 2009 (UTC)

SYNOPSIS

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. Additionally, I like to add a new function that offers better protection against malicious update attempts

DESCRIPTION

There are simply too many functions in this key. They can be misused and though I love the fun factor of it all, it does not add to security. I hence propose to give the user the option to install a hardened version of the firmware, that lacks various functios like URL surfing and CapsLock double clicking to activate sending a password. I suggest adding 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'].

SKIP (Spare Key Identification Protocol)

AUTHOR

fortean - 23.6.2009

SYNOPSIS

The SKIP protocol is a non-mandatory extension to any authentication subsystem that recognises the Yubikey. SKIP may only be invoked on systems that support at least 2 factor authentication. SKIP enabled subsystems will invoke a procedure to enable a spare key IF all alternate authentication factors validate AND a valid authentication Yubikey token is presented to the system AND it can decode the token AND the contents of the secret id match the expected value AND the token session counter has a value of zero.

DESCRIPTION

A Yubikey can get lost, stolen or destroyed. If the key is stolen or lost and is used as the only authentication factor, this potentially compromises the confidentiality, availability and/or integrity of the protected data. Therefore it is common practice - and mandatory for subsystems that support SKIP - to enforce the use of at least one other authentication method, for example a passphrase. If a user looses his/her key the data is still protected by the alternate methods.

However, to restore the original multiple factor authentication, the key needs to be replaced. SKIP will detect the use of a replacement key and invoke the applications SKIP key replacement routine. It is entirely up to the application developer to determine the inner workings of that routine: it could be as simple as to reset the application's internal counters and allow continued usage of the new key or may for example present a popup that informs the user his key has been disabled and invites him to visit the server admin, bringing his passport and a Yubikey (which will be programmed and enabled on the spot).

In practice: if a user looses his key he first obtains a physical replacement. The replacement key then needs to be programmed with the AES secret, public ID and secret ID of the original key - but with the session counter set to zero. Then the user would plug in this key and visit all SKIP enhanced servers where he has an account, taking great care not to unplug the key until he is done on all servers. He will need to log in using the replacement key and his other credentials. The SKIP enhanced server will then detect the '0' session counter and enter the (re)authentication logic.

NOTES

  • I assume that the AES key and secret ID are available to the programmer of the replacement key, but not neccessarily to the user of the key.
  • The current implementation of the 'ykpersonalize' reprogramming utility for Linux already sets the session counter to zero.
  • Implementing SKIP does not require changes to current Yubikey hardware/firmware nor changes to Yubicom provided software (e.g. 'ykpersonlize').
  • As any new key also comes with a zero session counter, it may unintentionally serve as it's own replacement key. This does not compromise security but can be a nuisance. To prevent this, simply plug and unplug any new key at least once before using it to register

Unified Access Control

The Yubikey could be used to unify physical and digital access control. I will explain this with an example.

Imagine a research facility with RFID-tags for physical access to the buildings, keypad-locks or just a key-lock for the access to specific rooms (with expensive equipment or dangerous material) and a simple username/password-LDAP server for all digital things like email, CMS, file-server, etc. So you have to carry something, remember a password, remember one or more 4 to 6 digit codes to ensure your access. And sometimes you have to search for the key to that room you need to go in. One could implement the Yubikey for all these authentication-systems:

The central part of this would be the LDAP-server where all personnel have an account that holds the Yubikey-database with public and private ID as well as the AES-cyphers.

  • Instead of a beige box that goes "beep" when you walk by with your RFID badge in your pocket to open the door, you find a small USB connector. You plug in your Yubikey, and submit an OTP to the LDAP server which authenticates you (and identifies you in the same process) and then unlocks the door.

Now, the USB architecture would not support this setup, so you'd have to build some magic box that gets OTPs via USB, emits them together with some additional information (which door?) through Ethernet and unlocks the door upon a positive response from the server.

  • The keypad-locks would be replaced with the system explained above.
  • Implementation of the Yubikey into the LDAP server is quite self-explaining.

To understand the advantages of this method, you have to consider the following things:

  • RFID - as an "over the air"-transmission system - will always have the potential to be insecure. Someone could record the radio-transmissions and could gain access with more or less work, depending on the built-in security of the RFID-system.
  • Keypad-locks are insecure by design: You always have to remember the key and over time, more people will know it - so the usual protocol dictates that the access codes get changed in a regular interval. Now you have to get the new code to everyone who needs to have access to that room and the whole thing starts again.
  • Username/password authentication is clearly inferior to a 2-factor authentication with the Yubikey - see www.yubico.com

But the biggest advantage of this unified access control would be, that all permissions could be handled by one system instead of two or three. With the right software, you could build up something like this:

  • The administration can only grant you access to the building in general
  • The IT-department can only grant you access to the digital services (all of them or a specified subset)
  • The respective authorities can only grant you access to the special rooms in their department.

All of this could happen via a nice AJAX-like interface through a web-browser that even non-IT-professionals can use. It could be made as simple as adding someone to a mailing list. You wouldn't even have to remember your public ID, because your Yubikey is linked to your LDAP-account - so all that has to be done is find your name in a list and put a checkmark in front of it. Simple as that.

Another advantage would be, that if a Yubikey gets lost or stolen, it could be revoked centrally and all access would be eliminated. You would then assign another Yubikey to that account and are good to go again without having to even look at the permissions again, because they are linked to the LDAP-entry.

--Kamikaze28 09:09, 28 February 2009 (UTC) Oliver Stengele

Drupal 

 Is there some support already?  There is some discussion in this link that discuss yubikey in drupal.
 Yes, there is a project around this: YubiKey Drupal Support

Joomla

YubiKey support for Joomla 1.5

AlFresco

Fingerswipeable Yubikeys

Multi functional Yubikeys

The Yubikey only supports OTP or static passwords. This proposal is to base the type of password on the duration the key is pressed. e.g, short for static, long (more than 3 sec) for OTP. This make the key multi functional and hightens the usability.

-- S. van der Baan

Verified by Visa Verification

In addition to the password that a user submits for the "Verified by Visa" service, a Yubikey field could be added as another security factor.

-- devel@silvermaple.neomailbox.net

Customer Loyalty Program

Please read here

Employee Time Tracking

Many small businesses still use time stamps to track employee hours. This has obvious problems with falsification of time stamps and having cards lost or stolen. A PC could be setup in place of a time clock and each employee could "punch in" by inserting their yubikey. This same sign in action could be integrated with the security system of the building allowing them access to protected areas. This setup would not allow a friend to be punched in early as the ubikey cannot be cloned and they would need access to the key to punch in.

The change would likely be welcomed by employees as the ubikey is easier to use than paper punch cards.

-- Dave Snigier

Payment application

Similar to the way that a person physically signs a check or other negotiable instrument, the authentication of a check writer does not currently exist. Credit cards contain numbers printed on the face of the card, and checks contain the account and routing number. A vendor could use a device equipped with a USB port to process payments for products and services as easily as they process the swipe of a card today without having the customer stand in a checkout line or have a waiter disappear with your card today. Anyone who has a YubiKey would have a way to uniquely identify their purchase for payment without the possibility of identity theft or authorization for services not listed on the display.

-- Kevin Meyer

Car Rental Checkin

A car rental agency could add USB ports to their kiosk. The user could preregister using the company web-site to check-in using the Yubikey. In this way the rental agency would be notified on their arrival and the customer would receive a printout of the location of the rental car, without having to visit the registration desk.

-- Jack Sporup

Credit Card Terminals Identification Verification

While this would take some clever marketing towards the credit card companies and terminal vendors, it would be very nice to see a terminals (i.e. at Wal-Mart) with a USB port that would allow a customer paying by credit card to use his/her Yubikey as an additional form of verification (past the usual handwritten "signature"). One possible implementation scenario follows:

The credit card company would provide a (secure) online interface that would allow a cardholder to submit his/her Yubikey signature; the Yubikey signature is now mapped with that person's card number. The cardholder can also tell the company whether or not the Yubikey is set to "OTP" or "Static" mode, which allows the card issuer to know what part of the signature actually gets verified against the signature in their database (as I understand this, the full signature could be used with Static mode, whereas only a shorter portion of the signature could be used with OTP mode). Accordingly, the credit card company could use a Yubikey signature submitted through a terminal with a card transaction and verify against the signature mapped to that card number that was submitted through the web interface. This of course would be a service provided to cardholders that they could participate in voluntarily.

-- devel@silvermaple.neomailbox.net

Electronic Lock

I use a lock of micro-controler in ELectronics and a good way to use the Yubikey would be to interface it with electronics. I was wondering if you could remove all the USB protocole and only send the CLOCK and DATA of the key on the pin of the Yubiko? For example: arduino.cc is a Atmega microcontroler that would connect easilly (without the USB protocol)

Thanks Patgadget

Hotel self-service check-in

A hotel could add USB ports to their door entry controls. Their web-site could offer self-service check-in features in which the guest would specify the use of their Yubikey. They would be e-mailed their room number and the time at which it will be available to them. At this time the door to the room would be programmed to respond to the guest's Yubikey. In this way the hotel guest could go directly to their upon arrival, without having to visit the registration desk.

Note that this service does not yet exist (to my knowledge), but is a suggestion for a useful real-world application of the Yubikey.

-- Andrew Cooper

Dvorak support

When implementing authentication servers and (and authentication clients), please add support for Dvorak keymapping.

One (very simple) way to do this is to try the key twice if it doesn't authenticate. First as-is, then as if it were written with a dvorak keyboard.

Example in python: 

 def dvorak2qwerty(s):
   """dvorak2qwerty(s)
   
   If keyboard mapping was dvorak, return what the user thought
   they wrote.
   """
   dvorak = "`1234567890[]',.pyfgcrl/=aoeuidhtns-\\<;qjkxbmwvz"
   qwerty_us = "`1234567890-=qwertyuiop[]asdfghjkl;'\\<zxcvbnm,./"
   m = {}
   for i in range(len(dvorak)):
       m[dvorak[i]] = qwerty_us[i]
   return .join([m[x] for x in s])
 
 def do_auth(token):
   try:
     return decode_token(token)
   except:
     return decode_token(dvorak2qwerty(token))

-- Thomas Habets <thomas@habets.pp.se>

Another option, if you're running Linux, is to use HAL. You can specify that the regular keyboard gets the preferred layout but that the Yubikey uses a layout like "us".

Example FDI-Policy can be found here. --Pokey 17:29, 24 April 2009 (UTC)

Here's a better solution. It is a bit of JavaScript that detects the keyboard layout based on the characters present in the otp and then converts the yubikey's otp in over 400 different keyboard layouts to "standard" modhex. Ideally the server should add support for the (rare) case a particular otp has a handful of possible modhex interpretations. Dholth 14:42, 12 August 2009 (UTC)

Static password on new session

When the authentication server sees a new session (session counter gone up since last authentication), do not return success, but instead return a message saying "you need to prepend your static password to authenticate the session". Once the session is authenticated the static password will not be needed until the Yubikey is unplugged and plugged back in. This way you get twofactor (password+yubikey) when you first log in and then you can have onefactor (yubikey only) for the rest of the day.

I have implemented this for PAM and my own authentication server and it works great. I haven't packaged it for the public yet though.

-- Thomas Habets <thomas@habets.pp.se>

DRM with YubiKey

This is an idea how DRM could be implemted using Yubikeys. You could create any number of keys that can be used to open documents, music, etc. Read more

-- Ilkka Pirttimaa

Supply color choice with Yubikey

As recommended on "SecurityNow", I have multiple Yubikeys. One will remain as provided, and one will be set for static passwords. I think it would be a great idea if the user could order a Yubikey in a choice of colors, as that will allow the user to know that a particular color corresponds to the one with a particular static password, or perhaps just for their own fashion sense.

-- Mark <drew2@indy.net>

Yubikey for use as a smart car key alternative

There is clearly a need for a better method for authenticating for car use. The auto industry has tried smart cards. Unfortunately, they are extremely expensive to replace (hundreds of dollars, can be over a thousand in some cases). Also unfortunately, their system has been cracked.

Why not use Yubikey? I suggest that when the car is sold (or transferred), three keys are provided. A master-key that can be authenticated against Yubico. With this key, and the car on-line in some fashion (either wirelessly or direct connection), the master key is authenticated. It can now be used to add/remove other Yubikeys in static mode. It could even delegate this capability to a particular Yubikey, or to another "master" Yubikey. With this capability, the car owner can easily add additional keys for other family members/trusted drivers. When transferring ownership, the master-key could be used to deactivate any other keys, unless they were provided. The other two keys would be the "normal" static keys for use with the car, to be used for unlocking and starting the car. Yes, the car locks and ignition would need to be able to use a USB port, but that is not a difficult engineering feat.

Here are some links that address the use of the smart keys: Hackable keys: http://www.theinquirer.net/inquirer/news/787/1009787/car-digital-keys-are-hackable

Car key replacements: http://www.consumeraffairs.com/news04/2006/03/car_key_replacements.html

-- Mark <drew2@indy.net>

Simplified Yubikey for Kerberos

While http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth might be a long-term approach for general OTP-integration with kerberos this option is not implemented at this time and will require client modifications. By making a minor modification to the yubikey firmware to allow locking the volatile counter and non-predictable counter it is possible to use standard PA-ENC-TIMESTAMP to achieve a "good enough" level of security and integration with kerberos that doesn't require any modification to existing kerberos clients (including Windows). A complete description is forthcoming...

Static and Variable authentication on one key

While the idea of Yubikey is excellent, there is a substantial limitation in the inability to have both static and variable keys available within one device; as such, logging into a machine when it is not connected to the network requires a separate Yubikey to login when connected. Were a script to be used to determine network status (i.e. path to Yubikey authentication server is valid and available), then, it could prompt from a variable authentication key (i.e. more secure); if it were not available, then, it could prompt for the static password, both accessible via separate buttons on the one key.

-- Neil (yubikey@neilzonecouk)

Yubihome

Yubihome - Yubikey as a physical access control to building - a digital key for opening doors.

Club_Voting

OTP on and offline

Rapid Application Developer uses YubiKey's OTP for on and offline authentication

YubiKey backup, keyed-alike OTP

The idea of losing a YubiKey is a recurring concern that can be eliminated.

Keyed alike YubiKeys

eZ Publish CMS

There is a new extension to add support to YubiKey to eZ Publish: YubiKey extension for eZ Publish by Quoc-Huy

Retrieved from "http://wiki.yubico.com/wiki/index.php/YubiKeyIdeas"
Personal tools
Authors/Administrators