TS-509 Filesystem AES Encryption Passphrase

[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.

[singeroi]

thanks for the input.. very informative..
simulation assurance vie

[sontom115]

this is an interesting discussion.. thank you for sharing

fiscalite assurance vie

[marcmarc]

Hi guys,

I am a newly Qnap owner, specifically the TS-239 Pro.
As I am using the encryption feature and I am also a security guy, I started to reverse engineer the qnap encryption implementation to ensure that the security is fine.

I have no clue why they make a big secret of how it works. its actually simple.

sorry guys, this post included wrong information. please read the new post below




issue 1 - minor: A good way to generate random data is to use collect some time, mac, ip address, source port of the http connection to the web gui, etc., concatinating that and running it through SHA1-256. This is then a secure enough seeding of the random number generator which is to be used. then generate random data, but before this is used, run it again through e.g. SHA1-256. And the result of that hashing is then the key to be used.

issue 2 - major: After cryptsetup was called (or an error occured beforehand) the files are deleted ... by calling unlink(). This is bad. by debugging the filesystem or using forensic tools (e.g. coroners toolkit, autopsy/sleuthkit, etc.) it is possible to recover the files in /tmp/ and by that gain access to the encrypted filesystems!
This is a serious security issue.
And the solution so simple:
before unlinking, just do a _secure_delete(FILENAME)

and here is an example function:

void _secure_delete(char *filename) {
int fd;
char buf[128];

fd = open(filename, O_RDWR | O_SYNC);
memset(buf, 0, 128);
write(fd, buf, sizeof(buf));
fsync(fd);
close(fd);
sync()
fd = open(filename, O_RDWR | O_TRUNC | O_SYNC);
fsync(fd);
close(fd);
sync();
/* unlink(filename); // do it here or afterwards ... */
}

it just overwrites the first 128 bytes with null-bytes which is enough for this special application in a secure way.
ah, and I just coded it down from mind, so it might not compile directly for one reason or another

[11vie]

Really cool! thanks a lot for this one..



rachat credit

[marcmarc]

I sent the issue of course to the customer support and got this reply:

Good day, Thank you for your suggestion for our product.
We will plan to impprove the security of the implementation in next version.

so when the next version is out I will check the implementation again.