TS-509 Filesystem AES Encryption Passphrase

[dmon]

By judging the number of replies not many people seem to care.

Maybe not everyone is writing a reply. For example I wanted to buy a TS-809 but now I'm waiting until QNAP gives us more information regarding their "enhanced" encryption mechanism. If they keep ignoring the questions about what they do with the password entered by the user I will build a storage system by myself.

[Jeroen1000]

You could choose freenas or cryptnas. Should do the trick and no obscurity there. But as for many users support is always a big plus. Qnap is said to have good support so this looked like a winner to me. C'mon Qnap humour us!

[dmon]

As fas as I can say, the TS-509 uses a standard luks partiton for encryption.
Therefore also the "cryptsetup" command works. Using

Code: Select all

cryptsetup luksDump /dev/md0

I've get displayed all the parameters of the encrypted partiton.

BUT, the problem is that I can NOT use the passphrase, entered on the Web Interface to do anything to the encrypted partition!
I looks like that the passphrase is not used as entered in the Web Interface but altered in some way before used for encrypting the filesystem...

Has anybody ever tried to create his own luks encrypted filesystem on the devices which are created by the webinterface?

I mean let the system create an encrypted device via the webinterface but afterwards do your own "cryptsetup create ... /dev/md0" with your own password, overwriting the qnap volume encryption.

I think then it wouldn't be possible to unlock the volume via the webinterface but it should still be possible to unlock the volume via "cryptsetup luksOpen .." and then everything else should work like you unlocked the volume via the webinterface. I this case you can't request support from qnap but you would be certain there is no backdoor to your data.

I would greatly appreciate it if somebody could try this.

Regards

dmon

[thanatos74]

good suggestion dmon!

I would try, but then I have to move all the terabytes of data to another place

/thanatos

[alienchaser]

Hi all,

I got a TS-509 some days ago. Then I started immediately to get into the system to see how it works.
What I wondered was the fact, that everything on mounting the RAID is hidden in some proprietary QNAP functions. When I've read your posts, I didn't wonder any longer.
For me, it's sure now that they have a backdoor, because key slot 0 in luks is always available and cannot be changed by the user (only key slot 1 changes, using the WebUI). The fact that I have not the absolute control over the system kept me sleepless. So I decided to install my own configured encrypted filesystem. I was lucky that the disks were still empty. How this is done is reported many times in the net.
What I can say is, its easy and everyone should do the same. I have chosen the recommended aes-cbc-essiv:sha256 and not the plain version, which can be compromised by patterns. Of course, it cannot be mounted anymore by the WebUI. But this is easily done using the autostart.sh. You can decide for the passphrase store yourself, for example a USB-key. Example autostart.sh:

Code: Select all

cat /share/external/sdi1/mypassphrase | /sbin/cryptsetup luksOpen /dev/md0 md0 1>/root/status 2>/root/status
/bin/mkdir /share/MD0_DATA
/bin/chmod 755 /share/MD0_DATA
/bin/mount /dev/mapper/md0 /share/MD0_DATA 1>>/root/status 2>>/root/status
/share/MD0_DATA/.qpkg/Optware/Optware-ipkg.sh start

autostart.sh can be created as follows:

Code: Select all

mkdir /root/temp
mount /dev/sdx6 /root/temp
cd /root/temp
vi autostart.sh
chmod a+x autostart.sh
umount /root/temp

I didn't discover any disadvanteges yet.

Have fun,
Thomas

[dmon]

Thanks alienchaser,

these are good news for me. Maybe I will now buy a TS-809.

For me, it's sure now that they have a backdoor, because key slot 0 in luks is always available and cannot be changed by the user (only key slot 1 changes, using the WebUI).

But maybe I still will build my own system because if a company build in such a backdoor who knows what else they have done.
That's alarming and untrustworthy!!

Regards

dmon

[alienchaser]

I fully agree !

[Nicodem]

Hi
yours post seems to be very interesting for me. I have 219 with one of the oldest firmwares where QNAP guys were trying to use encryption with 219 product. Afterwards it occured that in business use encryption slows down too much 219 and they have decided to skip this feature with all newest firmwares.

This left me in a position when I must use the old, early beta firmware because I have both my disks encrypted. And I preffer slow encryption then none.

As you seems to have much more technical background with disk encryption then me, could you please advise how to change file for HDA and HDB disks? Yours script seems to be working for RAID configuration, yes?
I have two separate disks which are visible as HDA and HDB devices.
My idea is to copy data from disk one to disk two, reformat disk one without encryption, install new firmware and then use yours sctipt to mount encrypted disk two. Then I would have new firmware, one unencrypted disk (1) and one with most important data still encrypted. Is there any chance that I will need only cryptosetup file? I have it now in my sbin directory so I can copy it somewhere else, install new firmware and copy back. New firmware does not include it.
Any other files needed then cryptosetup executable?

Another question- is there any chance of use some kind of dummy partition? I mean feature like in TrueCrypt - that you dont have to encrypt whole drive, you can encrypt one file and use it as new encyrpted filesystem. With such possibility I would reuse a lot of space at drive1 still with encrytpion...

[raid4all]

But maybe I still will build my own system because if a company build in such a backdoor who knows what else they have done.
That's alarming and untrustworthy!!

They still avoid answering direct questions. See this post:

http://forum.qnap.com/viewtopic.php?f=12&t=13370#p62471

QNAP sales department seems to be sleeping.

[AndyChuo]

Now, for some reasons, I would like to add another key to unlock the encrypted partition.
As fas as I can say, the TS-509 uses a standard luks partiton for encryption.
Therefore also the "cryptsetup" command works. Using

Code: Select all

cryptsetup luksDump /dev/md0

I've get displayed all the parameters of the encrypted partiton.

BUT, the problem is that I can NOT use the passphrase, entered on the Web Interface to do anything to the encrypted partition!
I looks like that the passphrase is not used as entered in the Web Interface but altered in some way before used for encrypting the filesystem...
Example: When I try to manually open the encrypted partiton with the command

Code: Select all

cryptsetup luksOpen /dev/md0 /share/..

and entering the same passphrase I would enter in the Webinterface, I only get the error message

Hi raid4all,

Yes the communication of locking/unlocking the file system between the web interface and the NAS is encrypted using QNAP's implementation to prevent the case if anyone is scanning the data travels in between. Therefore the system only accepts the QNAP encrypted passphrase sent from the web admin backend.

Andy

[AndyChuo]

If they know what they are doing there is no reason not to explain how things are done. Encryption with AES256 done right, using good keys is so secure there is NO reason what so ever not to explain. So I'd say they either know they have done something bad (like "protecting" the real symetric key with some weaker algorithm or perhaps they have a back door to "help" customers that has lost their key) or they don't know what they are doing so better not tell anyone. Having done some military grade work with encryption I know how easy you kan botch things up destroying the benefits from a good encryption algorithm.

Hi peris,

Thanks for your comments and regarding your concerns about the key management, both key slot 0/1 were created and encrypted using the passphrase you entered when setting things up and the the reason of having 2 key slots is because of the key management we use when user is changing the passphrase (slot 1) there must be at leat 1 key exists (key slot 0). There's no such back door you mentioned. And about your request of having an option for users to input/import their own AES key we are not considering this option and will announce once they are available.

Andy

[petur]

And about your request of having an option for users to input/import their own AES key we are not considering this option and will announce once they are available.

s/not/now/ ?

[peris]

Yes the communication of locking/unlocking the file system between the web interface and the NAS is encrypted using QNAP's implementation to prevent the case if anyone is scanning the data travels in between. Therefore the system only accepts the QNAP encrypted passphrase sent from the web admin backend.

I see... so basically You've traded providing a security function (scrambling the passphrase) against assurance (trust/proof that the security function really does what it is expected)?

You would rather not explain how this scrambling is done in detail, as that would make it easier for an attacker (because the method is not strong enough if it is explained)? And as a result you get questions on the implementation that you can't/won't answer?

Have you considered using (/requiring) HTTPS from the web interface? That should probably be a better/stronger way to prevent sniffing and not requiering "additional key management" (scrambling) that have assurance issues?´

Or perhaps including a checkbox to make additional password management (scrambling) optional (and thus avoiding tha assurance problem)?

[thanatos74]

Andy,

thank you very much for your explanations how AES encryption is implemented and how key management is done on QNAP devices respectively.
Now I can understand, why two keyslots are used.

Furthermore I hope, that there is a typo in

And about your request of having an option for users to input/import their own AES key we are not considering this option and will announce once they are available.

I think this should mean "...we are now considering this option..."????

Maybe I'm just lost, but there is still something I can't understand.
As you explain, you are encrypting data between the web interface and the NAS to prevent scanning this communication.
Now, what I cant understand is how someone should scan this communication if not already logged onto the NAS?
If thats the case, we might have a bigger problem than a secure passphrase communication as this person could easily copy/delete all data on the NAS (if I assume that the encrypted filesystem is mounted)

I'm really looking forward for the implementation of the "use my own key" feature. This renders this hole secure communication thing needless (hopefully).
I would prefer if I can put my key on a USB Stick - either the stick is there at boot time or not and the encrypted filesytems gets mounted or not.

/thanatos

[peris]

...Furthermore I hope, that there is a typo in

And about your request of having an option for users to input/import their own AES key we are not considering this option and will announce once they are available.

I think this should mean "...we are now considering this option..."????

It seems to be a typo - see Andys post in:
http://forum.qnap.com/viewtopic.php?f=1 ... =10#p63341

Yes, we are now considering adding this option for users to input their own AES256 key themselves. Details will be anounced once they are available.

But what "considering adding" really means in practical terms is still a question.
Also note my suggestion:

Looking forward to a "bring your own AES key" option.
You also might consider having an option to get the AES key generated, but omitting the extra key management and thus beeing able to manage luks from the command-line and avoid assurance issues.

This has not yet been answered by QNAP - hopefully they are busy working on a "bring your own AES key" option as suggested.

Maybe I'm just lost, but there is still something I can't understand.
As you explain, you are encrypting data between the web interface and the NAS to prevent scanning this communication.
Now, what I cant understand is how someone should scan this communication if not already logged onto the NAS?
If thats the case, we might have a bigger problem than a secure passphrase communication as this person could easily copy/delete all data on the NAS (if I assume that the encrypted filesystem is mounted)

No answer from QNAP yet - while we wait for a QNAP answer I'll give you my 25 cents on the subject (just ignore if not interested):

I think the threat QNAP is adressing is snooping the passphrase on the network when transported between the WEB UI and the NAS by an agressor not able to access/log in to the NAS. (Because - if you already has a trojan in the NAS or an agressor already is logged in to the NAS - as you indicated above - there is not much chance to prevent the agressor/trojan from reading the encrypted disk.) Network topology influenses how big problem network snooping is in practical terms, but cheap switches sometimes broadcast packets on all ports if overloaded/attacked.

The security function "disk encryption" (only) protects an un-mounted disk (for example a stolen NAS that is powered on). However - it is important to protect the "key" and all key management and user interaction handling the key's passphrase (protecting the security function - "encrypting the disk") so the "thief" can't steal the passphrase first (thus the key) and then steal the NAS. (Also important to protect the NAS from letting a agressor getting a bridgehead in it, but that is another topic).

Personally I think QNAP "scrambling" is the wrong way to adress network snooping concerns:
1) Instead - secure all communications with the NAS using standard protocols (HTTPS - easy to trust for users) or only when managing the key/passphrase.
2) The indicated method that QNAP uses seems to be close to "security by obscurity" - the added security depends on the agressor not knowing how it is implemented (a dangerous assumption).

Basically QNAP seems to think (or orginally have thought) that the added protection against network snooping (of the passphrase) by "scrambling" (mandatory added key management) is more important than assurance and ability to use both web interface and command line to handle luks.

I think not.

The security function "encrypting disk (using AES256)" strength of mechanism is somewhat let down by QNAP current handling of the key:
a) (significant problem) a unprotected/or weakly protected (only scrambled) channel from the web-interface is used when managing the key passphrase (much weaker than the rest of the functionality for the disk encryption)
b) ("minor" problem) the stored symmetric key is protected by a asymmetric mechanism. That is weaker than not storing the AES256 on disk but probably OK for business/home use (standard luks) if implemented in a clean way without assurance problems.
c) (big problem) assurance is important (do not comprimise assurance for a small increase in security function). What proof has QNAP that they have not implemented a backdoor even when they say they have not? We must trust their statement on the basis that they are good guys and haven't been forced by possible government mandates to provide a backdoor. See how quickly discussions got started in this thread - when the additional key management and dual slots was discovered.

QNAP now seems to (correctly) have found that - providing a "bring your own AES key" option (as requested) handles both the assurance problem and the strength of mechanism issues.