If you mean the operators' physical locations, sure, that could help.
If you mean servers, the FBI complaint claims that SR 2.0 server was hosted in a foreign country.
> "In or about May 2014, the FBI identified a server located in a foreign country that was believed to be hosting the Silk Road 2.0 website at the time. [1][2]
[1] https://news.ycombinator.com/item?id=8568219 [2] https://pdf.yt/d/RpyX9_xmapTkhmkb
In the end, your allies offshore may only be as loyal as the force they're willing to ignore. And your friends may only be as trustworthy as the information you choose to share with them.
Edit: Link to that poker takedown news http://www.covers.com/articles/articles.aspx?theArt=234980
Oh I wish that was true but we are in our fourth? decade of the War on Drugs, Authorities don't care, they just hire more people at tax payer expense.
War on a Noun.
If you run a single-server hidden service, the NSA can track it (unless you think otherwise - tried to initiate discussion here[1]).
Once they track it, they will get your hosting provider to cooperate and before you know it, your server has been imaged and that irrevocable .onion private key is in the authorities' hands. The most you'll see from your end was some downtime, which a cooperative host (an assumption here, granted) would cover up for the FBI (status update: rack/sector/DC failure at XXX).
They can now impersonate your server, MitM you, the works. After that, in order to move, you have to literally move to another onion address.
What you're saying makes sense if there is anyone who habitually rotates servers as a matter of OPSEC, but that sounds like an invitation for disaster.
AFAICT the name of the game isn't whack-a-mole, because when the NSA sees the mole, it will whack it.
It's "bury the mole in the moleyard" - multiple mirrors so as to make locating the actual service very unlikely.
For offline analysis and to be used as evidence, presumably.
> Did SR2 not use full disc encryption using LUKS? (...) longest private key ever
So the process for you would be slightly different: There would be a "power outage" in your rack, your encrypted disk would be imaged and (unencrypted) bootloader would be bugged.
Then they'd wait for you to see that your server had some issues, upon which time you'd have two choices:
-enter your private key to resume the service.
-abandon the server.
The correct choice would be (2), but you don't have enough information to make that call.
I'd compare the bootloader to a known good image as an early boot step and if it isn't what you expect immediately start destroying data. :-)
Here's how I would do it:
- I assume that your hard drives are in RAID. I gamble that they're in RAID 1 - most typical - and strip one out while the server is still running. Some kernel messages are logged, whatever.
- I start imaging the disk. If it isn't a mirror of the other after all, I strip the remaining drive(s) out and start imaging them too.
- While the disk(s) is/are transferring, I patch both your boot loader and your kernel with a rootkit. This should be laughably easy for the level of adversary we're talking about.
- When the disk(s) are done, I power cycle your server. I may cold-boot your RAM and get the passphrases there if i'm lucky. The downtime was either seconds (if it kept going with one RAID 1 disk) or <however long the imaging takes>.
- When you realise your service is down you may contact customer support. In that case they will respond (with their usual timing) about something-something-blown-fuse-UPS in your rack.
- When you log onto your server, you will most likely be faced with the passphrase input and most likely will go for it, but even if you don't...
> I'd compare the bootloader to a known good image as an early boot step
If you do so after you've given away the passphrase, you've lost already. Destroying the data won't help, as they have the encrypted copy of it and you just gave them the key.
I don't think you could detect a good boot/OS rootkit remotely at all. One would cover for the other. You can't unplug the disk and examine it. You can't plug a read-only drive in and boot some forensic tool. All you have is your lying bootloader and your lying OS. Your encrypted partition doesn't protect the integrity of the binaries there either, as after it's been decrypted, the rootkit would happily intercept any values that would give it away.
I'm not sure how you could ensure hardware security without ensuring physical security. Usually, physical access == pwned. Maybe TPM changes/will change that, but I somehow doubt it. Some other routes not covered here (probably easier, heh): Getting host to decrypt your TLS/KVM session where you typed the passphrase in the first place, malware in firmware on misc devices, etc.
Well, you won't be getting the kernel, its on the drives. It would have to be in a separate partition so you can start it before mounting the sensitive filesystems, and you may have a key that the bootloader uses on it, but in either case if you are not present and a sever goes offline you basically have to do the following:
Verify the ROMs integrity in that first stage - before you put in the key for your actually sensitive data. That means you need open firmware or some mechanism to hash the ROM that is installed, you need to have a means to read it in its entirety, and then you need to hash it.
I say open firmware because you need to be able to guarantee the FBI couldn't embed a backdoor firmware. If you can get open spec / openfirmware mainboards and verify their authenticity only then can you be safe.
Then you verify the kernel, which is much easier because you can compile it yourself, maybe even pad it with some random and scramble the ELF tables in some custom orientation.
And then you need to worry about how you input the key - if its by USB, you can backdoor the USB and network controllers and keylog in hardware depending on the vendor and model of the mainboard. Over the network, just the NIC is in question, because any secret sharing over ethernet better be over a secure connection.
But that should be it. It is a fine line at best, and a bottomless pit at worse, but there are ways to try to be hardware secure.
Does such a mechanism exist? If you can do this[1] from BIOS, why is it safe to assume that the same can't be done for the dump-bios-image routine? AFAIK the BIOS handles this in real-mode [2] (overrides the OS), and "returns" the image by copying it somewhere in low memory. So, you're trusting the BIOS that it's copied the right data out for you. (goodguybios)
> I say open firmware because you need to be able to guarantee the FBI couldn't embed a backdoor firmware.
This reminds me of this NSA RAID controller rootkit for Dell Poweredge Servers [3]. Nuts. Every closed firmware on your servers is a potential hiding place to someone with (soldering-iron-to-the-motherboard) physical access.
In our Dread Pirate use case, you don't even have to think that far as you can't ensure your own BIOS. Who are you going to buy TPM servers [4] from, when you're defending against the FBI? Intel? HP?
The Rootkit wikipedia page is alarming, to say the least. [5]
--
[1] A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers http://phrack.org/issues/66/11.html#article
[2] http://en.wikipedia.org/wiki/Real_mode
[3] http://resources.infosecinstitute.com/nsa-bios-backdoor-god-...
[4] http://en.wikipedia.org/wiki/Trusted_Platform_Module
[5] http://en.wikipedia.org/wiki/Rootkit#Bootkits ("Bootkits??")
[6] https://www.blackhat.com/presentations/bh-usa-07/Heasman/Pre...
This is the whackamole I was talking about. The time between when they identify the server and getting the provider to comply is enough in certain countries to set up an alternative location. Hosting companies aren't gonna want to play this game forever, ESPECIALLY if they're getting good money out of it.
Use Docker to wrap up the front-end and make it easy and portable. You can then spin up a new iteration of the site on a new VPS in a matter of moments. It can download the DB entries from that blockchain, decrypt, and then keep the DB in memcache/redis. To speed things up, you can also do daily encrypted DB dumps to a DHT address and write the DHT address into the blockchain to bootstrap the service restart.
Once the DB is bootstrapped and caught up, the site can register itself on the Onion network and since it'll be the newest entry, traffic will start ending up at the new site pretty quickly.
Such a system could be automated pretty quickly where a person could register VPS's at Linode, Digital Ocean, AWS, etc. Then write some kind of encrypted config file into a blockchain so the site software would pull down the config and make the transition to the new provider automatically. Could be an automated daily move and by using a blockchain as an intermediary for communications it prevents worries about making mistakes with accidentally leaking IP addresses at each new service provider.