Faulty disk encryption implementation?

[peris]

I'm interested in a TS439/639 and a key selling point is the disk encryption functionality. But I'm (and others in forums) concerned that the implementation might be flawed (or at least not as secure as it should be) and the marketing material suggests. Could you please set my mind at ease.

It seems that you use a passphrase to protect the real AES encrypton/decryption key in stead of allowing the user to select to input the real key directly (probably protected by a asymmetric algorithm).
Is that correct?

If that is the case the strenght of the mechanism (for confidentialiy) is much much lower than it should be and below what you can create with freeNAS-type of distributions if you know what you are doing. One problem is that the asymmetric passphrase-unlock mechanism is weaker than the symmetric AES algorithm (weakest link in the chain decides the strenght of the chain). But the big problem in this approach is that you might for example have added a separate backdoor passphrase that your tech support can use to unlock customer disks if we forget the passphrase. I do understand the need for such a mode of operation, but please understand that backdoors (if present) always leak (and for people that actually are interested in using encryption there is no way we can trust a implementation that allows for back-doors).

So, what I'd like to see is an "high security (confidentiality)" option (checkbox in GUI) to input the AES256 key myself (from the keyboard, or by temporary inserting an USB drive with the key in a file) the few times I do need to restart/upgrade (users of higher end models use UPS to protect from power failures). Should be really easy to implment (mostly just sidestepping the passphrase part thus avoiding weaking the mechanism).
Is this available or (when) will this be available?

Also - if there only is a passphrase-unlock mode of operation (as suggeted above) the marketing material is misleading as the protection is not AES256 strengh at all and should therefore be removed from all marketing material. If there also is a high security mode as suggested above there is no misrepresentation.

Best Regards
/peris

[raid4all]

Unfortunately - pretty sure that is a correct description.

You probably will need to create a NAS based on a linux/BSD dist yourself or opt for a higher end product from HP, IBM, Sun or Intel.

Or perhaps QNAP would like to compete with real storage/NAS suppliers - the more expensive models such as 8xx seems to indicate that.

Interesting to see if QNAP responds...

[QNAPIvan]

Dear raid4all & peris:
Thanks for professional comments, allow me to feedback at below:
1. Currently the NAS systems, TS-509/639/439/809 series, support AES 256-bit encryption. Once a specific volume is set as encrypted one initially, a corresponding password key or key file will be created for the usage of unlocking. The required password length is 8-16 characters.
2. For the AES 256-bit security level concern, QNAP added more key management mechanism & handling besides of the 8-16 length of password.
3.

One problem is that the asymmetric passphrase-unlock mechanism is weaker than the symmetric AES algorithm (weakest link in the chain decides the strenght of the chain). But the big problem in this approach is that you might for example have added a separate backdoor passphrase that your tech support can use to unlock customer disks if we forget the passphrase. I do understand the need for such a mode of operation, but please understand that backdoors (if present) always leak (and for people that actually are interested in using encryption there is no way we can trust a implementation that allows for back-doors).

It is not true.
4.

o, what I'd like to see is an "high security (confidentiality)" option (checkbox in GUI) to input the AES256 key myself (from the keyboard, or by temporary inserting an USB drive with the key in a file) the few times I do need to restart/upgrade (users of higher end models use UPS to protect from power failures). Should be really easy to implment (mostly just sidestepping the passphrase part thus avoiding weaking the mechanism).

It is a good suggestion and we will take into consideration.

Cheers,

[peris]

Thank you QNAPIvan for your answer.

1. Currently the NAS systems, TS-509/639/439/809 series, support AES 256-bit encryption. Once a specific volume is set as encrypted one initially, a corresponding password key or key file will be created for the usage of unlocking. The required password length is 8-16 characters.
2. For the AES 256-bit security level concern, QNAP added more key management mechanism & handling besides of the 8-16 length of password.

Yes, exactly what (and how) you have done additional key management is important. I do know something about this area I know how easy it is to do things with good intentions that don't actually strengthen the mechanism as intended (but leaves a false sense of security). In my experience - many commercial grade implementations unfortunately are not as good as their manufacturer think they are. Your implementation might of course be very good - but then again how would I know?

3.

One problem is that the asymmetric passphrase-unlock mechanism is weaker than the symmetric AES algorithm (weakest link in the chain decides the strenght of the chain). But the big problem in this approach is that you might for example have added a separate backdoor passphrase that your tech support can use to unlock customer disks if we forget the passphrase. I do understand the need for such a mode of operation, but please understand that backdoors (if present) always leak (and for people that actually are interested in using encryption there is no way we can trust a implementation that allows for back-doors).

It is not true.

Sorry, i don't follow - what statement(s) is(are) not true?
(A)" asymmetric passphrase-unlock mechanism is weaker than the symmetric AES algorithm" or/and
(B) "have added a separate backdoor passphrase that your tech support can use to unlock customer disks" or/and
(C) "there is no way we can trust a implementation that allows for back-doors"

Of course - if (and when) you implement a "high security (confidentiality and assurance)" option as indicated most of my concerns will go away.

[peris]

...
You probably will need to create a NAS based on a linux/BSD dist yourself or opt for a higher end product from HP, IBM, Sun or Intel.
...

I'd prefer to buy a product that has support, rather than building things myself. I know there are products available from IBM (partners) and Sun (partners) that probably will do things the right way, but they are at least a factor of 10 times more expensive than QNAP.

Also, I think it is kind of fun if an outsider like QNAP (no insult intended) could give SUN/IBM and their military/government expensive stuff a real challenge in confidentiality/assurance area.

[Jeroen1000]

Mr. Peris,

Could I bother you to explain the potential security problem in more detail? I did get a lot of it, but not all. Please allow me to explain:

As I understand from your explanation a symmetric encryption (256-bit AES) key is used to protect the data on the NAS. If someone would get hold of this key it is game over. You would like the option NOT to store this key on the NAS itself but to input it when needed. Am I correct so far?

Your main issue is how this key is protected (Qnap's implementation). Could you elaborate how this key is most likely protected? I understand this is done with a 8-16 character password, but how does this work?

I'd be most grateful,

Jeroen

[peris]

As I understand from your explanation a symmetric encryption (256-bit AES) key is used to protect the data on the NAS. If someone would get hold of this key it is game over. You would like the option NOT to store this key on the NAS itself but to input it when needed. Am I correct so far?

Yes, Yes and Yes (also see below)

Your main issue is how this key is protected (Qnap's implementation).

Well, Yes and No

The protection of the AES256 key will be weaker than not storing the AES256key on disk in the first place (so an attacker need to crack AES256 using brute force). An attacker (having a protected AES key on disk) now "only" need to handle the protection of the AES key.

It seems that QNAP provides a "random" AES256 key. Generating a good random key is not so easy as it might seem (a significant part of creating a good security system that uses cryptographical technology is spent on carefully considering randomness in various contexts). (Generating a few millions of "random" keys and analyzing them can sometimes show unexpected patterns)

The implementation of this protection of a stored AES256 key is not disclosed and verifiable. So QNAP could have made a mistake while implementing the protection AND/OR (this is the big issue) added a backdoor (passphrase) to make it possible for them to "help" recovering disks when users forget their passphrase (or required to do so by government agencys - a variant of key escrow).

Could you elaborate how this key is most likely protected? I understand this is done with a 8-16 character password, but how does this work?

I'd rather not speculate on a more detailed level. However I do recommend reading articles such as http://lukenotricks.blogspot.com/2008/0 ... large.html and http://lukenotricks.blogspot.com/2008/1 ... d-aes.html

[Jeroen1000]

The protection of the AES256 key will be weaker than not storing the AES256key on disk in the first place (so an attacker need to crack AES256 using brute force). An attacker (having a protected AES key on disk) now "only" need to handle the protection of the AES key.

I agree, but many software implementations (Simp for messenger traffic and PGP) use some kind of passphrase mechanism to protect the symmetric key. I must read up on how this works again, as it has been a long time since I refreshed my knowleadge. But PGP is considered to be very secure.

It seems that QNAP provides a "random" AES256 key. Generating a good random key is not so easy as it might seem (a significant part of creating a good security system that uses cryptographical technology is spent on carefully considering randomness in various contexts). (Generating a few millions of "random" keys and analyzing them can sometimes show unexpected patterns)

let's hope they moved the mouse around enough . I see your point though I must admit I myself often do not make it random enough:-).

The implementation of this protection of a stored AES256 key is not disclosed and verifiable. So QNAP could have made a mistake while implementing the protection AND/OR (this is the big issue) added a backdoor (passphrase) to make it possible for them to "help" recovering disks when users forget their passphrase (or required to do so by government agencys - a variant of key escrow).

Are you saying it is possible to encrypt (or secure, I assume they would use encryption to protect the AES-key) an encryption key whose encryption can be removed, not only by the user's passphrase but also by a secondary passphrase only Qnap (should) know? This would bother me a lot more than the key not being random enough. As I see it (and I believe that is what you want too) it would be nice if we could provide our own AES-key which is not saved on the NAS.

There are still a few (potential) security shortcomings which you may not be aware of :

• During the normal operation of the device the AES-key would be held in RAM memory until the device is shut down. If there is a security breach via the many service the NAS provides an attacker could get hold of a RAM dump....Synology is 'famous' for its flawed security. Netgear fares the best as many of their users are very much security minded. Too bad they do not provide encryption, yet. I do not know how well Qnap fares in this department. The more services the more dangerous it becomes to keep everything up to date.
• Secondly, the Linux equivalent of the Windows page file should also be encrypted. If not the key may leak into this (partition on Linux) file.
  At the very least this file should be overwritten on shut down but that will not be enough to hold of a determined attacker.

I'll take a look at the link you have provided. Please ignore my ramblings as thee answer to my questions is perhaps provided in your links.

[peris]

But PGP is considered to be very secure.

All things are relative... PGP has other goals.. Still a long way from pure AES256 using a good key (not stored on disk).

Are you saying it is possible to encrypt (or secure, I assume they would use encryption to protect the AES-key) an encryption key whose encryption can be removed, not only by the user's passphrase but also by a secondary passphrase only Qnap (should) know? This would bother me a lot more than the key not being random enough. As I see it (and I believe that is what you want too) it would be nice if we could provide our own AES-key which is not saved on the NAS.

Yes, that is a big issue compared to possibly weak randomess (I'd still create quite a few keys making sure to reset the clock between - some random generated keys are not really particulary random). Sure they could create a backdoor if they wanted (or were forced) to (depends on protection method). You mentioned PGP above - an example of having many "passphrases" beeing able to decrypt (unprotect). I don't have a encryption enabled QNAP so I could not experiment myself. Not beeing able to make heads or tails of the available documentation I asked QNAP (first post in this thread).
Yes, I would like a bring-your-own-key option. QNAPIvan seems to thing that might be a good suggestion - so there might be some hope. Creating a good AES-key is not for everybody so there should also be an option to have one generated. Also - of course there should be a function using a passphrase (current function) for those that can't be bothered.

There are still a few (potential) security shortcomings which you may not be aware of :
...

Yes, there are several security issues not mentioned in this thread. In my view the main threat disk encryption (discussed here) can protect from is somebody stealing the QNAP and after restart trying to get access to the data. A lot can be done to handle other security threats - I have not critically looked at QNAP in comarision with other NAS that way. To seriously handle more security threats I'd consider looking at storage systems certified according to ISO/IEC 15408 at at least EAL4+ with a suitable protection profile (but then we are talking about more expensive systems).

I'll take a look at the link you have provided. Please ignore my ramblings as thee answer to my questions is perhaps provided in your links.

Lets hope there is some interesting information in the links.

[Jeroen1000]

If you are interested scanning my NAS with nessus (http://www.nessus.org/nessus/) helped me considerably to close many security holes in the Netgear system. The worst matter is most (all actally) CGI scripts/software run as root. Does Qnap provide SSH access to the NAS? This way one who has an encyption enabled Qnap may be able to reveal what Qnap is doing. But this possibly voids warranty ...

If my Netgear could handle it I would have installed DMcrypt or True Crypt myself.

[petur]

Does Qnap provide SSH access to the NAS? This way one who has an encyption enabled Qnap may be able to reveal what Qnap is doing. But this possibly voids warranty ...

Yes, you can even configure what port it listens on. Doesn't void the warranty. Login is admin only, unless you replace it with OpenSSH (search this forum on how to replace)

[AndyChuo]

It seems that you use a passphrase to protect the real AES encrypton/decryption key in stead of allowing the user to select to input the real key directly (probably protected by a asymmetric algorithm).
Is that correct?

Yes.

If that is the case the strenght of the mechanism (for confidentialiy) is much much lower than it should be and below what you can create with freeNAS-type of distributions if you know what you are doing. One problem is that the asymmetric passphrase-unlock mechanism is weaker than the symmetric AES algorithm (weakest link in the chain decides the strenght of the chain). But the big problem in this approach is that you might for example have added a separate backdoor passphrase that your tech support can use to unlock customer disks if we forget the passphrase. I do understand the need for such a mode of operation, but please understand that backdoors (if present) always leak (and for people that actually are interested in using encryption there is no way we can trust a implementation that allows for back-doors).

No, there's no such back door you mentioned.

So, what I'd like to see is an "high security (confidentiality)" option (checkbox in GUI) to input the AES256 key myself (from the keyboard, or by temporary inserting an USB drive with the key in a file) the few times I do need to restart/upgrade (users of higher end models use UPS to protect from power failures). Should be really easy to implment (mostly just sidestepping the passphrase part thus avoiding weaking the mechanism).
Is this available or (when) will this be available?

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.

See my other replies for your other concerns regarding to the disk encryption feature.


Thanks

[peris]

]So, what I'd like to see is an "high security (confidentiality)" option (checkbox in GUI) to input the AES256 key myself (from the keyboard, or by temporary inserting an USB drive with the key in a file) the few times I do need to restart/upgrade (users of higher end models use UPS to protect from power failures). Should be really easy to implment (mostly just sidestepping the passphrase part thus avoiding weaking the mechanism).
Is this available or (when) will this be available?

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.

Thanks for answering.
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.

[Korrel]

Important new information can be found here:

http://forum.qnap.com/viewtopic.php?f=11&t=18863