Wednesday, May 14, 2008

Phone as a security token?

It is a good thing to notice that other people have got same ideas and even more, implemented those.  When that happens, idea probably isn't totally useless.

This came to my mind when I today started to think mobile phone as a security token that could add "something you have" dimension to the login process of a desktop terminal. In short my idea was that desktop computer could be constantly "pinging" a certain bluetooth hardware address, and when that device no longer is available then desktop will automatically lock itself. Think about following use case and you will get the idea: you are sitting at your office working with your desktop. Your colleague arrives and reminds you that the meeting is about to begin and you must rush. You grab your mobile phone and run to the meeting. Probably you forgot to lock your desktop and now anybody can use your user account. 

An easy solution to this would be that if desktop were pinging your terminal, the desktop would lock itself when the connection is lost. With Google I found  some applications that are able to do this: LockItNow and BTWatcher.

Because the simple use case (locking terminal when bluetooth connection is lost) is already implemented, I began to think about the reverse: unlock desktop when mobile phone becomes available. Obviously that shouldn't be done just by discovering some device (about bluetooth security issues, check this document).

What do you think about this idea: unlock the desktop when identification is done with bluetooth so that desktop sends a challenge to the terminal, terminal signs that challenge with PIN-locked client certificate and sends the response back to desktop. This way would be possible to implement a "poor man's secure id" system that adds an additional security to desktop environment. In addition to username and password, user must also carry a bluetooth device with a known hardware address, that bluetooth device must be able to accept and sign desktop's challenge and user's client certificate must be correct.

Did I just reinvent the wheel - has this already been done?


No comments: