Java Security Programming

Roughing a YubiKey

2008-06-28T07:02:00.000-07:00

How tough is the YubiKey? Suppose to tough... Since I got my static password one I have put it on my key ring where it is flanked by hard steel keys hitting it all the time I would imagine spending most of its time in my pockets.

Doing fine so fare...

YubiKey 1.3.0 and Static YubiKey Passwords Review

2008-06-18T16:29:00.000-07:00

There is a new firmware for the YubiKey being beta tested, here is the forum thread about it. They wanted to give out keys to known YubiKey users (those that can produce an OTP) so testing will happen. Natural I signed up and today I got two keys:

The left one is special: It produces a static password, same character sequence every time. While it can not be used to give the strong client authentication of an OTP it absolute has it uses. For example how many characters do you use for your personal computer login (>0 I hope ;-)?

Well, I just made an new user in my old XP environment with a very long password...

Works great while logging in, small trick in registering the password: Since the YubiKey produces an enter after password typed I could not register the static password in the XP widget pushing the green ring since it has to be entered twice and the enter event triggers the completion of the registration, so never got the second chance... What I had to do was to capture the password in notepad and do copy and paste.

Mind you, the robotic enter is a feature: it makes logging in to computer realy smooth once you have registred the password. One think I found after been trying it a few time was that it really is faster to log in this way then typing in a long for human strong password.

My resource post on the YubiKey
My YubiKey review

YubiKey review

2008-06-07T15:25:00.000-07:00

Here is a review of the YubiKey after I have been playing around with one a few days.

1. Using the YubiKey to log into a Web Application

There is one application you can start experience the use of a YubiKey as a tool to authenticate yourself on the Web right away: The Yubico forum. There you need a YubiKey to log in as a user for posting. When you register you have a choice to also define a pin code to be used when logging in. I did choose to define a pin code so I would be in the typical two factor authentication situation where such devices as the YubiKey are used. Glad I did, because that gave me an interesting observation:

When I log into the forum I am presented with a form not much unlike the form to log into my online bank: One field to type something I know (here that is the pin, for the bank it is a password) and one field to type in a one time password (OTP) proving I possess something (here that is the YubiKey, for the bank it is a dongle giving me an OTP to read of a small LCD display when pushing a button after inserting my smart bank card into it (phu...)).

Now, here is the difference: In the bank log in situation it does not matter in what order I do enter information as long as I have provided both password and OTP when I push the form's OK button. But in the forum log in scenario I must enter the OTP last because the device will do an 'enter button push' after the OTP has been feed into the field. And an enter button push normally means 'I am done, send the request to the server'. Of course it does not have to mean that, but it normally does, and it does so in the forum's log in form. So if I happen to do the OTP first with my YubiKey before entering my pin I will send a request missing my pin information and be rewarded with a pin missing error message.

Now, my point is that this way of operating is a feature of the YubiKey, and a very cool feature I think. But a feature user friendly interface designers need to relate to and take advantage of. At the very least you should have text informing end user that the OTP is to be provided last in the form, but better probably having the user interface work like that the OTP is entered last. That could be by activating the OTP field when ready or working in some kind of wizard fashion.

2. Giving the key to a coworker

I walked over to my unsuspecting colleague, gave him the YubiKey saying it was some cool Swedish technology that goes into his USB port, watched him mount it and had us focus on the tray area because the first thing I was going to point out was the message that pops up showing it being seen as an USB keyboard. Nothing happened. He had put it in with the wrong side up! You can do that with this USB gadget! The lighting condition happen to be a bit challenging at his station: bright sunshine through windows and the side of his laptop with USB ports in the shades so the ring on the up side where hard to see. Not a big problem because users will learn after use that the golden contact strip are also signs of the up side. Still, I think future key design may consider making the up side more explicit.

But when we got the thing put in correctly he jumped straight to the nearest field (his browser's address field) to generate an OTP, I quickly explained to not push, just rest the finger on the circle of cool green light and he had no problem confusing firefox.

3. Capturing the OTP in a Java desktop application

The company I work for, we develop desktop clients using the java Swing API. So one thing I was interested in right away was how easy it would be to get the OTP in a Java/Swing program. So I simply made a dialog having a text field (the JTextField class to be accurate) and wrote some callback code similar to:


otpField.addActionListener
(
  new ActionListener()
  {
    public void actionPerformed(ActionEvent e)
    {
      System.out.println(otpField.getText());
      // In a real app. here would be code to do 
      // authentication sending the OTP to a server.
    }
  }
}

When does this callback method get called? Well, the actionPerformed method is one you can register to wide range of widgets. If registered to a button it is invoked when user push the button. On a JTextField it is invoked when the user hit the enter key when the field has focus...

Thats right, the YubiKey invokes my actionPerformed callback method when the OTP has been populated in the field! It could not possible be any easier to integrate in our solutions! The automatic enter feature is one that beside it 'being a USB keyboard' does this easy.

I think it is likely hat similar ease of integration will be found using other well designed GUI toolkits also.

Wrap Up

I liked the concept of the YubiKey once I learned about it on the web but now that I have experienced it first hand I do like it even more!

Developer of services and applications that are going to utilize the device will need to take into account the nature of the gadget I think. But then it seems to offer the possibility of a more user friendly authentication process than many of todays two factor authentication solutions.

I also like the goal of Yubico of wanting to be the IKEA of authentication solutions, from the Yubico welcome page:

"Yubico's mission is to make Internet identification secure, easy and affordable for everyone. Inspired by IKEA and Amazon.com we deliver flat packages of do-it-yourself tools: We sell the YubiKey hardware online and provide you the basic SDK for free, no license cost included. And you can take the basic SDK to build your own full-fledged, customized strong authentication service."

Coming from small company developing niche solution in need of security I like that and hope they manages to stay true to that vision.

My resource post on the YubiKey

Got my first YubiKey!

2008-06-04T11:57:00.000-07:00

Got the device from "Søta Bror"! Now on with hacking (the good type of hacking) with it...

My resource post on the YubiKey
My YubiKey review

A YubiKey Simulator

2008-05-31T07:25:00.000-07:00

Still no YubiKey :-(.

However I can play around with a YubiKey web simulator an early YubiKey hacker named hasterguf has made :-).

And here is it's source code.

My resource post on the YubiKey
My YubiKey review

The Yubico Forum

2008-05-26T02:43:00.000-07:00

I edited the resource list in my previous post on Yubico's YubiKey to include a forum they now have. I think it is clever that they uses the YubiKey to give write access to the forum: it gives developers a chance to use the key for a real web application straight out of the envelope. I would imagine any YubiKey hacker would register as a forum user anyway.

A gem for developers already posted in the forum is the test vector post, using information here a developer can get a lot of code written and tested while waiting for mail man to show up with the device.

If you have questions but yet no key it is my experience that mails to Yubico gets answered rather promptly.

My resource post on the YubiKey
My YubiKey review

An One Time Password (OTP) USB Keyboard Emulator Generator Device called The YubiKey

2008-05-22T03:13:00.000-07:00

I am going to have a look at this USB authentication solution from a company named Yubico: The YubiKey.

The big selling point with this is how platform independent it is (no drivers needed) and how easy it supposedly is to integrate. What it does is that it feeds the computer an one time password through your USB port acting as an USB keyboard when the end user pushes it's button. So it only uses features virtual all computers used by humans must have.

Ordered one two days ago, it is just across the border (me in Norway and Yubico in Sweeden) so one could hope to have it soon, but there is an airport strike in my country now that could delay snail mail I guess and perhaps they are empty after got some fame by this Security Now podcast...

The basis of it's workings:

The generated 128 bit password contains AES encrypted information that allows a server (that also know the secret AES key embedded in the YubiKey) to verify that the password is indeed a new one.

Resources with meat I have found related to the device:

The company.
The key.
A 2007 Security report. This was going to be an independent report, however the author then started to work for Yubico so it is not independent. Also as time passes and the YubiKey product get updated relevance may diminish.
Yubico's forum (requires a YubiKey to post).
Open source YubiKey projects hosted at Google Code listed here and are discussed in this google group.
Yubico's collection of external resources: articles.
Yubico's monthly newsletter.
Transcript of Security Now! Episode mostly about YubiKey.
MP3 File of above episode.
Secure Id News interview with Yubico CEO Stina Ehrensvärd in this podcast.
A YubiKey web simulator with source code.
A site that has taken it in use for authentication.

My YubiKey review

Public key secure communication using Diffie-Hellman key agreement

2008-03-06T04:04:00.000-08:00

In the mid 70s a revolution happened in cryptography: The invention of public key cryptography. Before this revolution only symmetric ciphers existed to encrypt and decrypt messages. They are called symmetric ciphers because the same key is used in the encryption step and the decryption step (running the cipher in reverse). The keys used with these ciphers are also known as secret keys since they are secrets not to be known by the enemy.

The problem is that prior to secure communication the secret key must be distributed to all parties that needs to communicate. This can not happen over the network since we yet has no way to secure communication before the keys has been distributed...

In public key cryptography the parties that are to communicate has key pairs that consist of a private and a public key. The public keys are given to or fetched over an insecure channel to or by anyone that wishes to communicate securely with the owner of the public key: The public keys are for anyone to know about. The private keys are secrets known only to the owner of the key pair.

After the idea of public key cryptography had been put forward several algorithms has been developed to do:

Secret (symmetric) key distribution, what is usual referred to a as key exchange or key agreement.
Public key ciphers.
Authentication (making sure a message is from who it claims sent it).

The very first algorithm to be developed to do secret key distribution using the concept of public keys where invented by Diffie and Helmman, and is known as Diffie-Hellman key agreement. It provides secret key distribution but not authentication.

Using this method two parties that are to communicate first compute their key pairs using some common public known data and exchanges their public key. Since the key pairs are computed using the same data the two parties will be able to compute the same secret key using it's private key and the other's public key. After that the secret key is used to encrypt and decrypt messages between the two parties.

In a client/server model it is natural that the server is the keeper and distributor of the common data, the data can be read from disk, data base or even computed when server starts up. In the java cryptograpy API this data may be represented by objects of the type DHParameterSpec. It is a small problem that this class is not Serializable because:

One may want to save this to a file for the server to load on start up, depending on how persistent data is handled it may be convenient to had this type serializable.
This is information that need to be distributed to client over the network, could very well be convenient to have this serializable then.

The U4JSP class TwoPartyDhKeyAgreement wraps the same data as DHParameterSpec but is serializable and adds properties and methods to make it convenient to implement a secure communication protocol using Diffie-Hellman key agreement.

Note that key agreement can be done among n participants of communication (see KeyAgreement), TwoPartyDhKeyAgreement is implemented for the in network programming all important two party (i.e. client/server) case.

See this section of TwoPartyDhKeyAgreement's java documentation on how it is used and I plan to blog more about code that uses this in client/server programming.

About this blog

2008-03-06T03:59:00.000-08:00

Plan to blog here about anything feel worth saying regarding security hacking in Java.

Code developed will be published under the Apache License, v 2.0 here.