Monthly Archives: June 2014

RFID password keeper emits secrets with user controllable timing


This little password keeper unlocks Windows by an RFID card. It is small form factor with the size of a name card holder. In fact the case is from a plastic card holder and a small opening is cut at the side to make way for the USB connection to the Teensy.


A Teensy 2.0 with a 13.56 MHz RFID card reader from StrongLink are wired together in I2C. The coding is done in the Teensy IDE, and took the advantage of the Teensy emulating as a USB keyboard to emit password on sensing the right RFID card.


I usually keep Windows passwords at work and bring this little guy to office. It is really convenient at workplace where practice is in place to lock Windows before leaving desk. Most of the time it worked like a charm unlocking Windows, but there are occasionally hiccups I decided to fix.

1) Some workstations required CTRL-ALT-DEL before typing in password – prior to the fix I usually did a manual CTRL-ALT-DEL but that’s pretty much defeat the purpose of having this password keeper. No problem the Teensy provided facility in its keyboard API to do so. However, sometimes the PC is too busy at the background while the screen is locked, maybe scanning virus during the lunch hour. Simply emitting CTRL-ALT-DEL and the password upon the RFID card is swiped may not get me pass the login screen. Usually in these cases the CTRL-ALT-DEL did get through, and after 4 to 5 seconds the password input screen opened as if nothing happened. The password emitted is lost. Even adding a short delay does not guarantee it works all the time.

A solution is devised by making use of a signal pin provided by the SL018 independent of the I2C wires. This signal line simply ON/OFF when a card is in range. What I can do now is code the sensing loop such that it can tell when the card is still on the reader. With this hint from the user, the password keeper can emit the CTRL-ALT-DEL sequence, and not until the card is removed from the reader, the password will not be emitted. Obviously the user controls when to remove the card from the reader by observing the appearance of the password prompting screen.

2) Second problem is the reverse of the first one, CTRL-ALT-DEL is not required yet the same password can be used. Or for some password typing other than the Windows login screen. I could have separate card for the same password, one with CTRL-ALT-DEL and one without. But that is not good enough. Again, the solution is to look for behavioral hints at the sensing loop to detect a brief contact instead of a long one. No CTRL-ALT-DEL sequence is sent before the password if the contact is within one second.

In summary, the modified sensing loop works like

  1. if tag present and authorized  {
  2. delay 1 second
  3. if tag is still present (using the signal pin) {
  4. send CTRL-ALT-DEL sequence
  5. while tag is still present { delay 100 ms}
  6. }
  7. send password
  8. }

The last enhancement made is to sense a special sequence of card contact, similar to Morse code, to emit password of higher sensitivity. Theoretically this add another factor of security as something you know, in addition to something you have. Well at least in theory it does.

Video below showing the modified sensing loop that support user controlled CTRL-ALT-DEL and password release timing in action. Notice the green LED is on when the card is in range, and the timing of password release exactly at the moment the card leaving the sensing region.