Quote Originally Posted by Flancer
Thanks for answer, I understand your position, but can not agree. Software for encrypting is used wide on DAS storages, and I can not understand why it is impossible in iSCSI target.
Key feature is that iSCSI is the block device technology, so volume can be encrypted on target side on block level. I think it is not so difficult to implement one more logical layer in Linux file system for encrypting. I see no difference if I type password for mounting encrypted volume on local storage or on iSCSI target.

Thanks again for discussion.
No need to agree - I'm here to learn and to share .

Concerning DAS I see a major difference to block-level access technologies - NAS devices handle the "local" file system themselves (FS to store the data on the DAS device) and only offer a network file system (I don't mean to limit to NFS here) access layer to the clients. Using block-level protocals, ie iSCSI, the client itself provides the file system handling - any FS-level encryption therefore would have to be handled at the client.

BUT: I get the feeling the above doesn't cover your concerns/requirements - re-reading your reply it seems that you want the iSCSI target to store the (block) data in encrypted format, which of course could be "easily" added to the target code. So I fully agree to your statement about the additional logical layer.

OTOH, I feel the security gain is questionable: Since the target needs access to the encryption key in order to serve the initiator(s), it either has to be stored on the target device or to be provided via iSCSI (or manually). From the target's point of view, it has to be accessible automatically, else a manual intervention *at the target* would be required once for any new iSCSI target, which is typically impractical.

If stored on and made available without manual intervention at the target, then I see no security improvement: power up the iSCSI target (even after theft) and you have access.

If not stored on the target, then the secret has to be transported to the target somehow - I know no "iSCSI way" of doing this. One might try to use the password used to authenticate the initiator - but then it would have to be transmitted from initiator to target in clear text or a similar way, so that the target can read and use it. Again, a limited level of security (although it certainly would secure against theft of the target device).

And of course the network between initiator and target has to be trusted, since all iSCSI traffic is "clear text" - separate networks, VPNs or alike would have to be used.

So I see multiple levels of security that are involved here (theft, privacy, access control). To gain precision, you might want to detail your security goal and the level of interaction (manual secret entry when connecting; "unlocking" of the iSCSI device once for all connects via DSS interface; or whatever you have in mind) - maybe the DSS developers will get a better understanding and others might jump in and support your enhancement request.

With regards,
Jens