New server for reading Yubikey

My current implementation uses Windows server for reading Yubikey on a front door. I have implemented several security features but I think I need more robust solution for securing keyboard capture.

I believe I have to change Design Rational Decision #1 and Decision #2.

My biggest concern is how I make sure USB on a front door can't be used as an attack vector to get into my system. My new idea is to use another low-end PC for capturing keystrokes and send them into local network as UDP broadcast. Message is seen by the Home Control server, which does validation, opens a door, plays messages etc. There is no need to encrypt messages cause Yubikey itself creates one-time-passwords -- Once used, you can't use it again. I have seen many ideas of using Yubikey for physical access and I believe this kind of approach could be useful more generally.

I found neat Gadget Computer from my closet. It is very small, low power PC. Only disk is missing, I ordered 2.5" SSD drive for that. My plan is install very light weight linux distribution on it and run code like this :

while (1) ( inp=read_standard_input; send_udp_broadcast(inp) )

I'll let you know when this is done - Now I'm waiting for SSD IDE to arrive.

PS. If you have any suggestion for linux distro please comment. My current plan is to install Debian.

Should I authenticate locally or from Yubico service?

Yubikeys are delivered with secret AES-key which is unreadable from the key. Same secret AES-key is stored both in Yubikey and Yubico's validation server. To be able to validate you have to have internet connection.

Because all code is open source, you can also run your own validation server. In that case you can reprogram Yubikey with your own secret AES-key and store that key locally into your own server. I had to make a decision which way to go.

DR-log:

Question :	Using Yubico validation service or local?
Alternative 1	Yubico validation service + Very easy validation (for example simple http request) + No need to reprogram keys + Access can be provided also friends with Yubikey, even through webinterface - Needs internet connection - You have to trust Yubico to keep your AES secret and state of internal counters
Alternative 2	Running own validation server + Works also when internet connection is broken + No need to trust any 3rd side - Need to reprogram all keys. Same keys can't be used to logon any other Yubikey-enabled service
Comments :	First of all I trust Yubico. Even if internet connections is lost, my PC can also die - I have to have also mechanical key and lock available for those situations.
Decision #3:	I'll use Yubico authentication service

How to capture keystrokes?

Yubikey is the one and only one time password generator hardware that acts as a keyboard. It's great for application logins but for this kind of application it's not so good: My PC has to autologon, my application must be running in interactive mode or I must be able to capture all windows keystroke events. I'm not sure if windows even sends keystroke messages if you haven't logged in. So I needed a autologon solution.

DR-log:

Question :	How to autologon into OS?
Alternative 1	Windows registry based autologon + Free + Unsafe -- Logon username and password is stored into registry uncrypted
Alternative 2	Commercial product: LogonExpert + Encrypts password + Robust solution + Ctrl+Alt+Del, a shutdown event, administrator’s banners, or any other window appearing before logon is bypassed automatically.
Comments :
Decision #2:	LogonExpert

(Just another Yubikey development idea: If Yubikey would act both as a keyboard and serial port, it could be used more robustly also in this kind of applications. It could even act as a "license dongle" sitting in back of a server, providing one time password through serial interface)

Backend hardware and OS

My home control is based on self-written event-driven rule-based engine, communicating with tens of microcontroller based nodes using CAN. It's windows application that runs as a service.

For hardware I have selected S635F Fanless MiniPC, with 2G memory and 60 GB SATA flash SSD.

I'm running Windows Server 2003 Web Edition. Security has been hardened as it's sitting in internet, behind a firewall of course. It provides mobile and web UI to monitor and control home equipments.

DR-log:

Question :	What OS?
Alternative 1	Windows + I have more knowlegde programming windows + Yubikey needs interactive application, not "system level" application. I know how to capture keystrokes robustly under windows - Need to constant security updates
Alternative 2	Linux + Considered more robust OS + Could be run on lower resources
Comments :	I just know windows better and it has never failed since 2004 when I started to run SmartPirtti.
Decision #1 :	Windows

Design Rationale

I will use Design Rationale methodology to record design decisions. All DR-decisions are tagged with label "dr". If you would like to follow decisions made, please be aware that you read in order starting from the oldest one. All earlier decision can and will have an effect to later ones. It is a good practice to record system design process using DR. If you later change your design you can always get back to Design Rationale documentation and check if that change would have had impact for later decisions. Other tags used:

• dr = Design Rationale decision
• state:Planning = This feature is under planning
• state:Started = Implementation has been started
• state:Done = This feature has been implemented
• yubikey = Yubikey related

PS. Please free to comment. I appreciate all ideas and I'll make a note if I adapt some of your ideas into my system!