Encrypted volumes in Open-E

[Flancer]

I am testing now DSS Lite as iSCSI target . Everything is ok, but I have a question:
Is it possible to integrate Open-E iSCSI with a solution for encrypting volumes, like, for instance, TrueCrypt. I want to use it on target side, not in initiator.



Thanks in advance for any ideas.

[asaph07]

Flancer,

Open-E has IPSec built into it. If you go to the Setup, Network tab, you'll find the IPSec function, where you can set the sytem to use IPSec, and set an individual IP address for access, or a range using a subnet mask. Using IPSec will effectively encrypt your data transfer, and allow only IP addresses you specify to connect.

Be aware that encryption does create overhead in your network for data transfer.

Asaph

[Flancer]

Thanks for your answer, Asaph.
I know about supporting IPsec, I need to encrypt volumes but not a communication....

[jmo]

Thanks for your answer, Asaph.
I know about supporting IPsec, I need to encrypt volumes but not a communication....

Flancer,

I wonder what you are trying to achieve? I am not aware of any "iSCSI way" of transferring the encryption key from the initiator to the target, so you'd have to store the secret on the target and make it automatically available to the target software. In that case, any client still can access the share, once properly set up - and even so if the DSS is stolen. So IMO you gain no security by encrypting under sole control of the target.

If you want to make sure that only a specific initiator (which possesses the proper secret) can access the data, you'll have either to create strong access control (ie the IPSec access mentioned above) or encrypt the file system on the block device (which means encryption on the initiator side). Unless, of course, there is an iSCSI mechanism for transferring the secret from initiator to target, which I haven't seen so far.

Regards,
Jens

[Flancer]

Flancer,

I wonder what you are trying to achieve? I am not aware of any "iSCSI way" of transferring the encryption key from the initiator to the target, so you'd have to store the secret on the target and make it automatically available to the target software. In that case, any client still can access the share, once properly set up - and even so if the DSS is stolen. So IMO you gain no security by encrypting under sole control of the target.

If you want to make sure that only a specific initiator (which possesses the proper secret) can access the data, you'll have either to create strong access control (ie the IPSec access mentioned above) or encrypt the file system on the block device (which means encryption on the initiator side). Unless, of course, there is an iSCSI mechanism for transferring the secret from initiator to target, which I haven't seen so far.

Regards,
Jens

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.

[jmo]

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