Yubico Forum

As a security enthusiast (not an expert or professional) I'm enjoying experimenting with my Yubikey and considering its potential. Here is an admittedly kludgey use case, but one that could be fun/interesting to implement.

Idea for Yubikey dual-use (static mode for pre-boot authentication & dynamic one-time-password mode for network auth.) scenario:

• Set Yubikey to generate known static password ( = password required to login to TrueCrypt protected boot volume)
  
  • Use Yubikey to authenticate at TrueCrypt pre-boot password prompt (potentially with an additional portion typed in by user)
• Windows startup script does following:
  
  • Detects plugged-in Yubikey, if ID matches then...
  • Changes mode from static to dynamic OTP mode and sets auto-navigation parameter to preferred (ie MashedLife), this allows a possible alternate use-case:
    
    • User could unplug the key at this point and use it at other stations as she would a typical dynamic mode Yubikey
  • User then could use key for network authentication (ie OpenID, MashedLife)
  • (In ultra-paranoid mode discussed later: at this point script could set a variable associated with the user-assigned portion of pre-boot password to value obtained from external source, or some other date/time based algorithm if offline)
• Shutdown script (actually a macro since I don't think TrueCrypt can reset the password of a system volume from the command line) does the following:
  
  • Resets password of system volume to new complex value (plus short user-assigned value -- this could be prompted-for or fixed)
    
    • Consider adding step here to send encrypted password via email or place on separate volume in case of failure of any subsequent steps or Yubikey hardware failure
    • This step is primarily to thwart replay attack -- if adversary stole Yubikey just long enough to copy static password, they won't gain access to the computer without knowing the user-assigned value.
    • Ultra-paranoid user could use information from an unpredictable external source (ie digits of closing NASDAQ? exact time of some recurring event? fallback= some other date/time based algorithm if offline) as part of the short user-assigned value as method of detecting if an adversary had accessed system
  • Changes mode of Yubikey to static using new password for TrueCrypt protected boot volume (minus short user-assigned value)
  • Powers system down (or hibernates)

The benefits of this system:

• Allows user to use one key for both pre-boot as well as network authentication
• Allows Yubikey to rotate static keys between boot-up sessions (minimizes risk window of replay attack from swiped Yubikey password)
• Allows user-assigned value (typed in after Yubikey static value during pre-boot authentication) to prevent access to their system even if adversary steals laptop and Yubikey

Does not protect against:

• Physically malicious adversary that forces user to grant access to system (though this could be mitigated by use of a hidden volume or OS)
• Sophisticated adversary that steals laptop, Yubikey, and gathered user-assigned value from keylogger or video (though the theft would likely be detected)
• More disturbingly, above scenario but only long enough to copy drive image and static value from Yubikey, then return them undetected. They would then have access to the copy without the user's knowledge. In the case of a software keylogger, this could be made more difficult by also using a separate pre-boot BIOS and hard drive password. It would not help in the case of a hardware keylogger or video.
  
  • To thwart the hardware keylogger or video observation threat, an alternate method for the user-assigned portion of the pre-boot authentication password could programmatically assign something that would appear random using an algorithm known to the user such as numerals of date computer last logged off multiplied by numerals of user's spouse's birthday. The benefit of this method is admittedly very small while the cost in increased complexity is high, and the keylogger threat would be devastatingly invasive in so many other ways that this method would not protect against.

The following requirements (at least) would have to be met before this system could become feasible:

• Programmatic or command-line access to tool for changing mode, static password, and auto-navigation parameters of Yubikey (Is there a plan for that to be made available?)
• Macro or scripting method that is capable of changing TrueCrypt password with adequate robustness and error-checking, and preferably added redundancy of emailing encrypted version of new password (definition of adequate here is necessarily subjective).
• User would have to accept increased risk and complexity of recovering from failure of:
  
  • Yubikey (hardware failure or software at point mode changed or parameters set)
  • TrueCrypt or password-resetting script/macro
  • Note: access to the system should be possible in the event of either failure above using TrueCrypt's Recovery Disk generated when the volume was first formatted.

Interesting idea! One thing I'd suggest is to reset password *after* the user logs in, immediately prepare the credentials for the next login. And this should be an *atomic* transaction. Anything fails inside the transaction it should not reset the password otherwise that will prevent users from logging in.

Since the shutdown process is hard to predict or manage. Image a sudden power outage, etc.

Cheers

_________________
The YubiKey Server Guy