Printable View
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.
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
Thanks for your answer, Asaph.
I know about supporting IPsec, I need to encrypt volumes but not a communication....
Flancer,Quote:
Originally Posted by 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.Quote:
Originally Posted by jmo
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 :) .Quote:
Originally Posted by Flancer
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
You have made big investigation of this question.:)
But in real life everything is little bit easily. I have a DAS with encrypted volumes. When I want to mount an encrypted volume, I manually type the password and add a key file (in USB stick, for instance). Tell me, why I can not do same in SAN (not in NAS)? The way of the entering password, for instance, is SSH. a key file can be added by the any way (on network, on storage between many other files, on USB stick or something else).
Of course, when the volume is mounted, it is decrypted and I need to use another way to make it safe. But when it is dismounted (the storage is switched off), I am absolutely sure that it is in safe condition.
I'm sure it could be done this way. The question is: How many users are out there that will use a block device (on SAN, big bucks) without having an automated way to mount the device? Or in other words: What major advantage is there over simply doing the encryption at the initiator's side?Quote:
Originally Posted by Flancer
When using NAS, there is no simple way of doing client-side encryption (unless, of course, you misuse the NAS to store a file that is used as a virtual block device by the client :eek: ). When using a SAN, there is - iirc all major OSes support encrypted file systems. So why the hassle (for the SAN vendor) of implementing it the complicated way and/or (for the user) of having to transfer keys to the SAN device (typically locked up in the CC) and telnet/ssh/WebUI to the SAN device to unlock prior to mounting?
I for sure prefer simple solutions - in my case, that would be a simple block device on the SAN and handling the encryption on the initiator's end. YMMV :)
With regards,
Jens