Dexter Kane's ultra paranoid encrypted NAS (Completed)

Go full Zoz and have the means to destroy your drives physically.

That'd be going full paranoid, but funny none the less.

2 Likes

For, an potential attacker preventing the disks from locking... or keeping the system powered on:
No one, not even the forensics teams would think someone would hook a mercury switch to the PSU;

So two conditions to ungracefully shut down the PC (aka, turn power off, flush memory -> flush keys) is the mercury switch and two intrusion switches =) They would need the bombsquad guys to get into it =)

1 Like

I'd just like to preface this by saying that I'm not a terrorist or a paedophile, I don't think being arrested is am actual risk.

Having it check with the phone was my original plan, the idea being that if I were arrested once the phone and the computer were separated form each other it would lock. But after thinking about it there were a lot of problems with this. For one this if the keys were on the phone, unless I had an opportunity to encrypt the phone then they would be able to unlock the disks. Plus I thought I'd run in to false positives and lose the ability to remotely access my storage.

So I went with having the keys on a VPS and having the servers ll check in with each other every minutes, thus way if contact is lost all the disks are locked and the key files are encrypted. It's unlikely that an attacker would have physical access to the vps unless they knew the configuration beforehand so once the keys are locked as long as the disks are also locked then it would be pretty hard to open them again.

2 Likes

Haha yeah I saw that. I think you'd want to be pretty certain of your programing and everything before implementing something like that.

Yeah the mercury switch idea I think is solid. The system really needs a physical hardware method of cutting power as soon as tampering is detected as not only are my scripts somewhat unreliable but you just can't rely on software once an attacker has physical access to the machine.

My scripts seem to work but there are a lot of steps in locking the disks and if one step fails the whole thing can fail and leave the disks unlocked. So I think I may actually give the mercury switch idea a go. I'll have to have a think about it.

For the paranoid a relay on the primary side of the PSU would be sufficient; For the not so brave, a relay shorting the reset pins should do.. or shorting the power-button infinite until released.

So either "movement -> cut wall-power from the PSU" or "movement -> force PC to reset, o. power off" are two ideas that come to my mind right now.

I would have to look up, which pin(s) on the 24pin need to be opened to immediately force a shutdown, as that also could work.

1 Like

Resetting would probably work, if I wanted to cut power I would have to actually cut the power (not just short the power button) as the BIOS in this system is a bit buggy and the system will come straight back on after a shut down.

I don't really know enough about electronics but it seems straight forward enough. Could be a fun project though.

Just be realy careful when messing with primary side power! I would recommend you to stick with 2ndary voltages and just use the reset header than.


A quick and dirty drawing; 12V or 5V depending on the relay (R) and the mercury switch (MS) and case switch(es) (CS)

1 Like

Thanks for that, I think using the reset is the easiest way and the keys will lock during the boot up so there's no chance of the disks unlocking again.

I think I'd also want to include a switch to arm and disarm it, something I can hide behind a vent or something and just stick a pin in to disarm. I could stick it on the reset side so when the pin is inserted the reset circuit will be broken.

You can use a opening contact either on the side that powers the relay, or on the reset side;
If you use it on the "primary" side where the mercury switch is, it will inhibit the relay from engaging; If you put it onto the "secondary" side the relay will engage, but no reset will occur.

Ah I see, yeah that makes sense.

Just found this at work, should make a good case intrusion switch

2 Likes

Perfect, seems to have contacts for both an closing and opening actuation =)

1 Like

Is this the sort of relay I would use for this?

http://www.ebay.com.au/itm/1-Channel-Relay-Module-High-Level-Trigger-12V-Expansion-Board-for-Arduino-Relays-/311591293292?hash=item488c49d16c:g:BuQAAOSwyQtVn09H

EDIT: Actually I think this may be easier

http://www.ebay.com.au/itm/DC-12V-1-Channel-Angular-Transducer-Tilt-Angle-Sensor-Relay-Module-/310826854222?hash=item485eb9674e:g:O5UAAOSwHnFVlYUZ

I can have the micro switches for the case intrusion detection and arming/disarming the system between the relay and the reset header. Or am I missing something?

Interesting post :) Thanks for sharing. I'm running a BTRFS pool of HD's and as a home user it's a no brainer for upgrades and flexibility.

Encryption is hard to get a handle on as lots of the info on the net is conflicting and often dated.

1 Like

Yeah I'm pretty impressed with BTRFS, I still like using snapraid for what I do but I came pretty close to converting the whole thing to BTRFS while I was doing this.

I was surprised how easily the encryption set up came together, I was expecting there to be much more hassle, especially in getting the disks to unlock on boot using keys on a network share.

The dissarm opening contact can be on the RESET side; The intrusion and mercury must be on the primarry side of the relay

Thanks, I think I've got it now.

I think Hillary Clinton should have hired this guy.

1 Like

Actually, if all the contacts that you are using are closing contacts (so they close the circuit when they are actuated) you dont need the relay.

Than you just put the case, movement switches parallel and the opening contact in series so you can inhibit the reset; that way you do not need external power.