Hello,

I'm a member of a non-government, non-profit voluntarily organization that focuses on teaching military skills and passing the associated values to young adults. The organization is state-independent, but it maintains friendly relations and loose co-operation with the government of it's country.

It was decided that a central database would be a valuable and practical tool to address specific logistical and organizational challenges. While the data is in itself harmless, it's security is critical.

If you have ever watched the classic movie Red Dawn you probably already know why the confidentiality of such data is essential. The premise of this film is of a foreign army invading the United States. One of the first things the invaders do after establishing foothold is confiscating documents containing the personal information of citizens who have bought firearms, seeing them as a potential, if not immediate, threat. It's a good example of truth in fiction.

There is every reason to believe that today a similar approach would be used in regards to electronic data - especially with cyberwarfare being the new media buzzword. The requirements here differ from plain "civilian" data security, as the party willing to obtain this kind of data will:

1) Have immediate and unrestricted access to the server, perhaps attempt to seize this data in a covert manner before any overt actions are taken.

2) Not hesitate to use any and all methods of coercion that would be considered effective in order to obtain said data.

3) Be expected to employ qualified personnel in fields of cryptography, computer forensics and security.

4) Be expected to ignore arguments of plausible deniability that would, in other circumstances, form a sufficient defense (in countries where password disclosure is mandatory, like the UK)

The data stored in such a database would not be crucial to the existence of the organization and it's permanent destruction would be fully acceptable if it were to prevent it's disclosure.

There exists a possibility of running this service anonymously, under an .onion address for example, however the goal isn't to provide security through obscurity. Hiding the service isn't by itself required, however this would enforce an adequate level of anonymity - otherwise every user is at risk of having his/her identity revealed. Most security problems are of PEBKAC variety and not everybody can be expected to have the necessary computer knowledge or awareness to use proxies or similar tools. That leaves those individuals at risk of having their identities easily compromised by having their home IP logged anywhere on the way to the intended host. On one hand using Tor means a guaranteed minimum level of anonimity at the cost of some overhead, on the other hand it does seem like overkill for the sole purpose of preventing careless users from connecting directly to the system with their home IP.

The server itself would definitely have to have it's own server room and full-system encryption. A power cutoff switch would be installed in every entry point to the room to make the retrieval of keys from the RAM a one-time opportunity. Using non-standard screws on the server casing and other simple physical barriers should make that particular vulnerability a non-issue.

The major difference in this scenario from a common "civilian" one is the need to address the possibility of individuals being coerced into revealing passwords or keyfiles by force.

The most obvious method to prevent the data from being obtained, as far as I see, is physical destruction using a remote kill-switch of sorts - but I'm not quite sure about how that would work in practice, or if anyone successfully managed to create a reliable and safe solution of this type.

The materials that would be the best for the job, or at least the ones I'd go for if I could, such as thermite, are illegal to posses and manufacture. In addition there is no guarantee that GSM networks or the internet will remain operational at the moment when the need to deploy such measures will arise, making satphones with a backup power source the only solution reliable enough - and that's not mentioning the technical challenge of making it at least do a tone-recognition or the cost of both creating and then maintanining such a device.

Unfortunately building a device that incinerates the HDDs with thermite, regardless of any steps taken to ensure safe operation and mitigate risk of fire, damage to equipment or injury to anyone, it still essentially amounts to clandestine bomb-making.

A remote kill-switch was the first thing to come to mind, however a solution which is as much as legally questionable is one that for obvious reasons can not be used. I am not aware of any other method that would remain operational for a reasonable time without external power, guarantee destruction of data in a short time-span, and at the same time remain stable, highly resistant to accidental/unintentional usage all while maintaining those qualities for a reasonable amount of time, 5 years or so.

Other than not putting the data out in the open in the first place, are there any more practical ideas for keeping that it safe under the outlined circumstances? I'd like to ask the community here for feedback, thoughts and ideas. What approach would be the most appropriate for this kind of data?


The front-end for the database will be done with some server-side language, at this point it could be anything from Ruby to PHP - at this time it's not that important but inherent inclination towards security and language maturity will be major factors.

I'll refrain from providing more details, though I'll gladly answer any relevant questions.

Regards

* Before anybody asks the stupid question of why would a non-govt organization need that kind of security: because gathering people's personal data makes one implicitly responsible for it's safety. Just because a total SHTF event may be a tangible threat only in the eyes of the tinfoil-hat crowd today, nothing absolves me of responsibility for what might happen to that data tomorrow or the day after that.