August 24, 201411 yr Is "Anti theft encryption", an interpretation of this? Does this mean it is not scheduled for neither 6.0, nor 6.1 or 6.2? Thanks
August 25, 201411 yr Author Is "Anti theft encryption", an interpretation of this? Does this mean it is not scheduled for neither 6.0, nor 6.1 or 6.2? Thanks The other forum post you reference is definitely where this came from and yes, it means it's not scheduled for 6.0, 6.1, or 6.2 yet. Doesn't mean it won't get added, it just means we have yet to figure out where it fits in its prioritization.
August 25, 201411 yr The other forum post you reference is definitely where this came from and yes, it means it's not scheduled for 6.0, 6.1, or 6.2 yet. Doesn't mean it won't get added, it just means we have yet to figure out where it fits in its prioritization. Thanks for your response! If in fact this goes down in the prioritizing process, it would really be great if you could, in the interim, provide some generic hook inside the md-then-mount process of the unRAID array start (and stop), so that a user can insert their own DM layer and probably mounting before unRAID does the standard share / user share setup. (e.g.: Do the unRAID md - then call a script, which by default just copies its input to output, passing it the md block device (/dev/md*) - then mount the block device the script returns unless already mounted - something to that effect. Similarly for array stop). This should be fairly straightforwrd to implement, and will enable the addition of an encryption layer, and perhaps other DM type ideas as well, by the user. No GUI support for now; no problem. Thoughts?
August 25, 201411 yr Author The other forum post you reference is definitely where this came from and yes, it means it's not scheduled for 6.0, 6.1, or 6.2 yet. Doesn't mean it won't get added, it just means we have yet to figure out where it fits in its prioritization. Thanks for your response! If in fact this goes down in the prioritizing process, it would really be great if you could, in the interim, provide some generic hook inside the md-then-mount process of the unRAID array start (and stop), so that a user can insert their own DM layer and probably mounting before unRAID does the standard share / user share setup. (e.g.: Do the unRAID md - then call a script, which by default just copies its input to output, passing it the md block device (/dev/md*) - then mount the block device the script returns unless already mounted - something to that effect. Similarly for array stop). This should be fairly straightforwrd to implement, and will enable the addition of an encryption layer, and perhaps other DM type ideas as well, by the user. No GUI support for now; no problem. Thoughts? This would require Tom's input / feedback.
August 30, 201411 yr This would require Tom's input / feedback. It would be great if he could provide feedback here, yes!
September 2, 201411 yr This would require Tom's input / feedback. Perhaps an expansion of emhttp_event functionality would serve this purpose well.
February 27, 201511 yr It is worth pointing out why this topic is named "Anti theft" and why potentially some user will want a second feature. The idea is that if someone steals your unRAID that they cant plug it in and access your data. This is not the same as keeping some agenecy or skilled attacker out.
February 27, 201511 yr This is not the same as keeping some agenecy or skilled attacker out. Yeah, those guys on TV can hack into anything!
February 27, 201511 yr It is worth pointing out why this topic is named "Anti theft" and why potentially some user will want a second feature. The idea is that if someone steals your unRAID that they cant plug it in and access your data. How exctly is that accomplished, and would that remove one of the best features of unRAID, namely you can take a drive out of your unRAID array and plug it into a linux distro and get the data off should your hardware fail? I'm just having nightmares again about the day my PS3 died. You might not know this but the PS3 has a built in hard drive which is replacable by individuals. So clearly when the PS3 hardware fails you just pull out the PS3 hard drive plug it into a new PS3 and get on with your life right.... WRONG, each hard drive was individually formated with an onboard chip to only be readable by that particluar PS3... so when the hardware fails even though the hard drive is good and the data is there you can't recover it... (Good job Sony!) Anyway, I'm only mentioning this becuase this is a concern of mine, not becuase I beleive that this concern will be realized.
February 28, 201511 yr Anti theft is probably not a good description. Your unRAID box would still get stolen, only when he plugged it in would a thief not be able to access your data. He would have to be a pretty savvy thief to work out how to use an unRAID box anyway. It's far more likely he would try to play FIFA Football or Minecraft, fail miserably, and throw it away. It's probably better to stick a piece of paper with your phone number on it and offer a reward for it's return.
February 28, 201511 yr The issue is not the guy who steals it... it is the guy he sells it to cause "he knows about computers he will give me good money". This may not even be direct, it may be after it has changed hands once or twice. Data is worth more than hardware and the days where crooks dont know this are long gone Either way there is value in not having to freak out that someone has relatively easy access to all your data. That IMO is what this feature is about.
August 18, 201510 yr Any update on this - being able to have encryption - or being able to roll our own would be great.
August 18, 201510 yr Author Any update on this - being able to have encryption - or being able to roll our own would be great. We are in discussions about this feature, but no news just yet. Know that it is an active topic right now.
August 18, 201510 yr Any update on this - being able to have encryption - or being able to roll our own would be great. We are in discussions about this feature, but no news just yet. Know that it is an active topic right now. Great news jonp! This and the ability to have more than 1 parity drive, and I'm GOOD...
July 18, 20169 yr Curious about news on this topic, I'm currently using a QNAP (TS-563) for this with the builtin AES encryption and seperate key which I only need to load during boot. Would be nice if unRAID would get this option. The QNAP also runs VM's, but I would like to switch-over to unRaid to have more control over my hardware and scalability.
July 18, 20169 yr the two threads are very informative, some of ya'll know some sh*T, however for the regular user like me who like unraid because it works on almost any hardware and I can stick any size disk to expand my storage. Its great for those who use unraid in a enterprise setting and need encryption, don't get me wrong this would be nice, but i'm thinking ahead when a 2 or 3TB disk fails and its encrypted how easy is it replace? or when the system fails and you need to move it to new MB and then something in the hardware hash or something doesn't work. The biggest fear is for me is implementing encryption and everything is working and one day boom, usb drive fails no way to recover, need a new USB key, do I now i have a group of disk that are paper weights (maybe). I am an unRaid fan but like some else already pointed it out, there's other NAS technologies that offer this already for free, and while i see the importance of this for unRaid to be able to claim that we have this technology . My own 2 cents here, why would i paid for license where i can get it for free and why choose unraid that just started offering this technology instead of XXX who has been offering it for quite sometime and it's well supported. This is just my opinion, I hope to see it this implemented at some point and I will keep reading updates, but to me personally this feels like a split in unraids. One for consumers and the other for enterprise. Nothing wrong with that tho
July 18, 20169 yr Encryption doesn't have to be implemented via the USB. It can be as simple as a password you enter when starting the array.
July 18, 20169 yr Limetech already has the infrastructure to offer optional array start denial. The V6 beta already requires connection to the mothership to verify key eligibility before the array will start, so if there was a market for it, I'm sure they would be willing to implement an optional feature that would use the same system to blacklist stolen keys. They say the phone home will be removed in the released version, and I have no reason to doubt that, but it's possible they could turn it into a marketable feature. It shouldn't be too hard to leave the "feature" enabled by request for specific license keys. At least that way a thief wouldn't have a ready to use box. It's not in any way a substitution for encryption, but I can see a business use case.
Archived
This topic is now archived and is closed to further replies.