Unless the cabinet is air tight, and uses a pressure sensor to detect itself being opened. It's "Is the cabinet open?" subroutine can be defeated by simply opening the cabinet where a sensor isn't located.
Basically cut the sucker open on the side.
:.:.:
Also by using a time sharing OS its likely you can induce a large network based load externally slowing its IO speed to the level you can open the cabinet, and "close" the cabinet from the sensors perspective while leaving it opened.
:.:.:
Further more data loss doesn't occur on door opening, thus the keys are still recoverable, because without it would be impossible to service.
A possible approach would be: keep the data encrypted, just decrypt it at the endpoint. Tarsnap for example does that. Or keep the keys on servers that are acting as proxies and decrypt the data. Or actually loose all data on door opening. Just drop it and use a replication like backblaze and S3 use. A harddrive lost? Allocate a shard somewhere else. A unit looses enough harddrives to require service? Just pull it, trash it, plug in a new one.
Given that the units are spread out further than servers in a datacenter, you probably want that anyways. Your service teams don't want coordinate access to the device, drive there and the homeowner does not show up for something as mundane as an HDD swap.
Likely extreme mirroring + no keys actually kept on the unit. They just store N byte chunks of data which a master somewhere fetches an decrypts at its leisure would be the best approach. (with key value pairs stored on that said machine).
Best approach not necessarily being the one that was put into production.
The fastest approach would be to store your key value pairs encrypted on the host device, and do your map/reduce functions locally so you only forward relatively useful data.
I think your suggestion of using a pressure sensor is a great mechanism. Then, as you say, you need to be able to restore the keys (stored offsite) so you can do maintenance.
This is an engineering problem: how secure do you want to be; how many mechanisms do you need to achieve that; does this come in under the cost budget. Your pressure-sensor solution alone is probably good enough for a large number of applications already.
But this is not a research problem: we don't have to solve homomorphic encryption!
Fine, thin, looped resistance wire - if you drill or cut through it, its resistance changes (either to infinite in case of a clean cut, or a couple ohms in case of two or three shorted-together loop).
> Also by using a time sharing OS its likely you can induce a large network based load externally slowing its IO speed to the level you can open the cabinet, and "close" the cabinet from the sensors perspective while leaving it opened.
Use a Raspberry Pi together with a UPS-backed fiber modem and a cellular modem backup uplink in case someone cuts the fiber, and the threat is basically neutralized (okay, someone may jam the phone signal, but then again this can be detected by carrier loss).
Unless the cabinet is air tight, and uses a pressure sensor to detect itself being opened. It's "Is the cabinet open?" subroutine can be defeated by simply opening the cabinet where a sensor isn't located.
Basically cut the sucker open on the side.
:.:.:
Also by using a time sharing OS its likely you can induce a large network based load externally slowing its IO speed to the level you can open the cabinet, and "close" the cabinet from the sensors perspective while leaving it opened.
:.:.:
Further more data loss doesn't occur on door opening, thus the keys are still recoverable, because without it would be impossible to service.