[Request] Use USB device for encryption key

[buggy82]

Agreed. I'm not a security professional, so I welcome any feedback from those who are.

Me neither, but I´ve been interested in IT security topics for some time. Unfortunately one needs to be a mathematical algorithm wizard to be able to assess encryption security.

My intention here was to contain the unlock password in a secure environment (within the NAS) instead of keeping it out in the open (on a USB stick).

The DOM is no such environment. Technically it is an internally attached USB flash drive.
What you need here is special hardware for this. Something like Wikipedia (en): Trusted Platform Module
TPM is implemented using dedicated secured hardware on the mainboard. From what I´ve read, it is frowned upon by the open source/open hardware community for being an proprietary and inaccessible gatekeeper on mainboards that prevent e.g. Linux systems from booting from it.

It was only to prevent the average person copying the USB stick (and associated identifier).

There are tons of simple disk imaging softwares out there. In fact any backup software is capable of copying such sticks with 3 simple buttons: "Select Source", "Select Target", "Go".
Someone trying to break into your server definately won´t use Windows Explorer or the MacOS one to copy your decryption flash drive.
Imho: Not worth implementing without dedicated hardware, like special USB dongles.

[OneCD]

Me neither, but I´ve been interested in IT security topics for some time.

Oh... I see...

My intention here was to contain the unlock password in a secure environment (within the NAS) instead of keeping it out in the open (on a USB stick).

The DOM is no such environment. Technically it is an internally attached USB flash drive.

I was not suggesting the DOM was a secure environment. And yes, I'm very aware of what it is and how it presents to the OS.

Imho: Not worth implementing without dedicated hardware, like special USB dongles.

I have suggested a method that can be implemented without requiring action on the part of QNAP. However, any method will have its problems. If the NAS admin is aware of the risks and is willing to take them, then it's on their head if it goes wrong.

Your turn: how would you do this with the environment available and without requiring 'special' hardware?

[buggy82]

Sorry, I did not intent to make you angry or so... English is not my native tongue so I may sound a bit harsh sometimes. Sorry for that!

The idea itself is really good, but it is never a good idea to rely on security by obscurity (USB drive copy protection) or presenting something as being secure while having backdoors/serious flaws in the implementation (decryption key "obfuscated" in DOM)

So, how would I do it?
In the best of all worlds, I´d use a retail encrypted USB flash drive with pinpad, something like this: [Image] [Example from Amazon.com]. Using such a key introduces an additional layer of security. If security demands are lower, one could - of course - also use a standard usb flash drive without encryption.

Since one can have different encryption keys for different volumes on the NAS, the USB flash drive should contain both: For each volume you need a volume id and the matching key. For this we need some sort of convention.

Example use case:
Assumption: Key file name is volume ID (Example: "12345-67890-abcde-fghij.key").

On boot execute a script on an unencrypted (boot) volume that performs the following steps
1. The NAS shall scan for encrypted volumes and external devices. It saves the volume IDs of encrypted volumes in a variable ($ids).
2. If it finds an attached USB flash drive, mount it and try to find files whose filenames match found volume IDs of encrypted volumes (Pseudocode: For each $id in $ids {if exists (usbDevice.getFileByName($id))} ).
3. For each matching pair: Automatically start to decrypt and mount the respective volume. When complete, emit a sound to make the user disconnect the USB key.

Else if one or more matching volume decryption keys are missing,decrypt and mount whats possible and fall back to standard behaviour (QTS login and decrypt with user interaction in Storage Manager with file or password).

Same if no USB flash drive is found.

Done.

What do you think? Pretty straight forward isn´t it?

[OneCD]

Example use case:
Assumption: Key file name is volume ID (Example: "12345-67890-abcde-fghij.key").

On boot execute a script on an unencrypted (boot) volume that performs the following steps
1. The NAS shall scan for encrypted volumes and external devices. It saves the volume IDs of encrypted volumes in a variable ($ids).
2. If it finds an attached USB flash drive, mount it and try to find files whose filenames match found volume IDs of encrypted volumes (Pseudocode: For each $id in $ids {if exists (usbDevice.getFileByName($id))} ).
3. For each matching pair: Automatically start to decrypt and mount the respective volume. When complete, emit a sound to make the user disconnect the USB key.

Else if one or more matching volume decryption keys are missing,decrypt and mount whats possible and fall back to standard behaviour (QTS login and decrypt with user interaction in Storage Manager with file or password).

Same if no USB flash drive is found.

Done.

What do you think? Pretty straight forward isn´t it?

Looks good to me (but I'm no expert) and it's close enough to what I suggested that I'm not likely to disagree with your process. I think you should code this up.

[buggy82]

I think you should code this up.

As I´m a complete rookie in shell scripting and QNAP app packaging, this sounds like a nice opportunity to learn something. I´ll think about that.

[Moogle Stiltzkin]

Personally, I think a user manageable biometric fingerprint reader would be a nice touch for them to simply swipe to re-enable the encryption and HDD data, but that's just my two cents dream i guess

another curious development. I thought it was a hoax or fake news at first, but apparently it's a real thing guess it's not somethong anthony weiner would be interested, considering how much exposure his gotten...
http://www.news.com.au/technology/home- ... 479d25186a

[Hank Moody]

@ukez We finally got some tension into this topic ..after 8 years man
@buggy82: lovely simplistic flow!
@OneCD: Even if you don't use qnaps-fw anymore /but seen you developed/coded a lot for it/ would you mind teaming up with buggy82 getting this job done straightforward? Simple tool/script into a qpkg so that even a no-coder like me could use it

On boot execute a script on an unencrypted (boot) volume that performs the following steps
1. The NAS shall scan for encrypted volumes and external devices. It saves the volume IDs of encrypted volumes in a variable ($ids).
2. If it finds an attached USB flash drive, mount it and try to find files whose filenames match found volume IDs of encrypted volumes (Pseudocode: For each $id in $ids {if exists (usbDevice.getFileByName($id))} ).
3. For each matching pair: Automatically start to decrypt and mount the respective volume. When complete, emit a sound to make the user disconnect the USB key.

Else if one or more matching volume decryption keys are missing,decrypt and mount whats possible and fall back to standard behaviour (QTS login and decrypt with user interaction in Storage Manager with file or password).

Same if no USB flash drive is found.

Done.

The one and only thing that could be altered for security reasons would be to not let the qnap start operating fully until the usb is removed. Sure the user itself, letting the stick on the nas after decrypting is an asshole. I'd just consider this for a v2; The sound should be enough of a reminder to remove the key, and the sound is surely easier to implement than everything else.

I would really love to see this tool coming alive!!

Have a nice saturday!

Cheers
Hank

[Hank Moody]

Any progress over here.. ?

[OneCD]

Happy to revisit this as I now have time to take on a new project (i.e. I'm bored. )

But before it can happen, hoping that someone (or several someones) can perform feasibility checks on a few items. I can't check for these as I don't use volume encryption.

So, we'll need to:

• ensure that it is possible to unlock a selected volume from the command-line with a saved keyfile. You'll need to show what you did to make this work. QTS must recognise that the volume is unlocked when you're done, so I suspect it won't be as simple as just unlocking with LUKS.
• check that [autorun.sh] still works during NAS startup - even if the volumes have not been unlocked. This is the easiest place I can think of to start checking for a connected USB device. [autorun.sh] is expected to be found on the DOM, but I don't know if QTS will make it to this point in startup (where [autorun.sh] is executed) in the event of a locked volume.
• put these first two tests together and ensure that volume unlocking can be performed in [autorun.sh]. If this works, then the rest is easy.
• find a universal method to make the NAS beep (HAL vs SOC).

[gasongasoff]

Did this feature ever get developed? I could totally use it. I can't use S3 sleep because my QNAP 10GBE add-in card is not compatible. Which means to save power I have to power off completely.

[Stefan5]

Any updates? That would be an awesome feature...

[jaysona]

Well, since we're all just spit balling here, and there is no real QNAP involvement, and we're well into the future of when this thread was first started, I'll say it's now time to forget USB memory stick and go with something like a YubiHSM now.

[Hank Moody]

@jaysona how would one configure an YubiHSM to work with qnap encryption? Would you mind linking some?

[jaysona]

A Google search for YubiHSM and full disk encryption will provide more than enough links for you to read.

If using a YubiHSM is not something you are familiar with, then I would not suggest using this, as it will require a lot of custom work on the QNAP, such a finding a free LUKS key slot among other things.