Yubico Forum

I would like to submit the following idea for comments:

I'd like to create a "yubivault", that is a computerized equivalent to
a secure vault, on a NAS for example.

A word of warning: For this application, a yubikey must be dedicated to
this usage only - For SSO on other site, you would use another one.

The idea is to encrypt some data using one or more yubikeys as keys.
The user may not know the actual key of the data on disk.

The purpose is to simplify the user's experience of disk encryption, and protect the data
from the thief of the data support (ie. the NAS)

It does NOT protect against an opponent that gains access to the disk AND the yubikey.
The protection does not work either when the encrypted partition is in use and thus
unencrypted : For me, this is a problem, I don't know how to resolve that...

Truecrypt is an example of a disk encryption program suitable for this.

The Initial use case would be :

- A partition (or a file on disk) is reserved for secret data by the user, he specify the size.
- He run the "yubivault init program" which can be either on command-line, or on a stack of interactive web pages,...
- The program generate an AES key suitable for a yubikey (or let the user enter its current one).
- The user insert the yubikey of his choice
- The program prompt him to *reprogram* the key with the this AES key.
- On agreement, the user is asked to push the button of the yubikey - The program now know the AES key and
the current sequence, and deduct the NEXT OTP it will receive from this key.
( - This procedure may be repeated with additional yubikeys )
- It can now generate a crypto material for the disk encryption program (i.e.: truecrypt), and format the reserved space with it
(This key can optionally be shown to the user - this will act as an emergency data recovery mechanism)
- This "disk key" is then encrypted with the NEXT OTP to be received from the yubikey, and the result stored on a non-encrypted part of thedisk,
and then erased from RAM.
- The user remove his yubikey, the program is ended.

When the user want access to its data, the usage usecase would be :

- He gain access to the NAS either by command-line of via web pages,
- He inserts the yubikey and push the button.
- On the other end, the server check the AES key and get the OTP, then use it to
decrypt (in memory) the file which contains the disk key.
- If successfull, the disk may be decrypted with the disk key. It then calculate the NEXT OTP to go and
reencrypt the disk key with it on the disk.
- If not successfull, this is fatal since the OTP cannot be regenerated : The user MUST redo the procedure.
I have yet to come with a solution for "resynchronizing" the server on the NAS and the client...

The unencrypted disk can now be used normally (samba/nfs/http/webdav/....)
A variant would be to export the encrypted disk via iScsi for exemple on the client's machine.

What do you think ? Do you see any impossibility to do that ? Will it achieve the goal above ?
Do you think it can be usefull ?

Thanks for the comments,

OB

It looks like you are using the "next" OTP as a key to encrypt the disk data. If so I don't know how you would be able to predicate what the OTP will be because of the 16-bit random data field and the time stamp which are both included in the OTP. Also, anything that will cycle power on the Yubikey (insert/remove) will advance the session counter which will change the OTP.

Tom

Yes, I think you are right, you can't predict the next otp with our technology, so you cannot use it for encryption. Also, the chances to lose an OTP are pretty high, I think.

To be able to use the yubikey for disk encryption purposes, if you don't want to use an online verification service (which can be problematic during boot), is to store the yubikey AES key on the machine somehow, and use that AES key to verify a yubikey OTP.

You could store the yubikey encrypted key in a PKCS#8 container, then to boot the machine you would need

1. to enter the password, to decrypt the PKCS#8 container, and

2. press the yubikey button the generate an OTP.

The software would verify the OTP against a local yubikey database. The security benefits over just passwords could be discussed, but it may provide a complication that makes it difficult for attackers to not bother.

/Simon

Okay, but then how do you avoid replay attacks ? You just have to remember all the previous OTP sent for a given yubikey in a database ?

Anyway, you are right - using only the AES key is IMHO useless compared to a difficult passphrase in this application.

The REPLAY_ERROR is detected after decoding and extracting the "counter" from the OTP sent in. You can reference the validation server's source code here:

http://code.google.com/p/yubikey-server ... ystem.java

_________________
The YubiKey Server Guy

You don't have to remember previous OTPs, just the Session Counter and Session Use fields for the last authentication. The Yubico server returns REPLAYED_OTP status if the OTP session counters are equal or less than the last stored value. Other server implementations should do the same to detect replay attacks.

Tom

Ok, I got it now.
I will work again on my idea,
thank you guys for your insights !