What size EMP device would be necessary to wipe all data in a Google-sized server farm, without major...
up vote
11
down vote
favorite
I'm not sure if it's even feasible, but I have a server farm in my book, of a size that puts it on par with Google's. I want to wipe out all the data stored on the hard drives, without destroying the servers themselves, most likely using an EMP device. This is assuming the device is within the farm itself, basically an emergency wipe.
An example data center is Pryor Creek (Mayes County), Oklahoma , 980,000 square feet. Google, for security purposes, doesn't release a lot of data. Let's say at least a few hundred thousand servers, as that matches what I have in my book.
If this is possible:
- What sized capacitors would it need? How long would it take to charge said capacitors?
- What are we looking at for coils? I've read 10-12 coils of copper tubing would create a rather massive field.
If it is not possible, I'd have basically the same questions, but for destroying the server farm. I'd prefer to leave the hardware intact, but can live with it if not.
Another idea beyond EMP would be welcome, as well, if an EMP device were not feasible. If this is the case, it would have to be something that is hidden from all the techs working on the farm, installed in secret by an extremely small team in the case of emergencies.
Effectively, the owner(s) want a secure way to instantaneously wipe every bit of data stored on the server, hardware based and in no way connected to the system. A kill switch. Better if they could kill it without destroying a farm's worth of servers.
physics computers electricity electromagnetism data-storage
New contributor
add a comment |
up vote
11
down vote
favorite
I'm not sure if it's even feasible, but I have a server farm in my book, of a size that puts it on par with Google's. I want to wipe out all the data stored on the hard drives, without destroying the servers themselves, most likely using an EMP device. This is assuming the device is within the farm itself, basically an emergency wipe.
An example data center is Pryor Creek (Mayes County), Oklahoma , 980,000 square feet. Google, for security purposes, doesn't release a lot of data. Let's say at least a few hundred thousand servers, as that matches what I have in my book.
If this is possible:
- What sized capacitors would it need? How long would it take to charge said capacitors?
- What are we looking at for coils? I've read 10-12 coils of copper tubing would create a rather massive field.
If it is not possible, I'd have basically the same questions, but for destroying the server farm. I'd prefer to leave the hardware intact, but can live with it if not.
Another idea beyond EMP would be welcome, as well, if an EMP device were not feasible. If this is the case, it would have to be something that is hidden from all the techs working on the farm, installed in secret by an extremely small team in the case of emergencies.
Effectively, the owner(s) want a secure way to instantaneously wipe every bit of data stored on the server, hardware based and in no way connected to the system. A kill switch. Better if they could kill it without destroying a farm's worth of servers.
physics computers electricity electromagnetism data-storage
New contributor
Comments are not for extended discussion; this conversation has been moved to chat.
– L.Dutch♦
Nov 27 at 23:50
1
To clarify, you're asking about a single server farm, not all of them? ( Google undoubtedly locates their servers in various physical locations. Are you just wanting to take out one farm it all?). That's also not to mention backup/redundant servers.
– BruceWayne
Nov 28 at 0:55
1
Sometimes I feel like worldbuilding.SE is full of terrorists who are trying to crowdsource the plans for their evil deeds...
– Kapten-N
Nov 28 at 7:37
Well, you could replace the moon with a magnetar. That would probably kill everyone, but would wipe every hard drive in the world and would leave buildings and physical servers intact.
– forest
Nov 28 at 10:17
add a comment |
up vote
11
down vote
favorite
up vote
11
down vote
favorite
I'm not sure if it's even feasible, but I have a server farm in my book, of a size that puts it on par with Google's. I want to wipe out all the data stored on the hard drives, without destroying the servers themselves, most likely using an EMP device. This is assuming the device is within the farm itself, basically an emergency wipe.
An example data center is Pryor Creek (Mayes County), Oklahoma , 980,000 square feet. Google, for security purposes, doesn't release a lot of data. Let's say at least a few hundred thousand servers, as that matches what I have in my book.
If this is possible:
- What sized capacitors would it need? How long would it take to charge said capacitors?
- What are we looking at for coils? I've read 10-12 coils of copper tubing would create a rather massive field.
If it is not possible, I'd have basically the same questions, but for destroying the server farm. I'd prefer to leave the hardware intact, but can live with it if not.
Another idea beyond EMP would be welcome, as well, if an EMP device were not feasible. If this is the case, it would have to be something that is hidden from all the techs working on the farm, installed in secret by an extremely small team in the case of emergencies.
Effectively, the owner(s) want a secure way to instantaneously wipe every bit of data stored on the server, hardware based and in no way connected to the system. A kill switch. Better if they could kill it without destroying a farm's worth of servers.
physics computers electricity electromagnetism data-storage
New contributor
I'm not sure if it's even feasible, but I have a server farm in my book, of a size that puts it on par with Google's. I want to wipe out all the data stored on the hard drives, without destroying the servers themselves, most likely using an EMP device. This is assuming the device is within the farm itself, basically an emergency wipe.
An example data center is Pryor Creek (Mayes County), Oklahoma , 980,000 square feet. Google, for security purposes, doesn't release a lot of data. Let's say at least a few hundred thousand servers, as that matches what I have in my book.
If this is possible:
- What sized capacitors would it need? How long would it take to charge said capacitors?
- What are we looking at for coils? I've read 10-12 coils of copper tubing would create a rather massive field.
If it is not possible, I'd have basically the same questions, but for destroying the server farm. I'd prefer to leave the hardware intact, but can live with it if not.
Another idea beyond EMP would be welcome, as well, if an EMP device were not feasible. If this is the case, it would have to be something that is hidden from all the techs working on the farm, installed in secret by an extremely small team in the case of emergencies.
Effectively, the owner(s) want a secure way to instantaneously wipe every bit of data stored on the server, hardware based and in no way connected to the system. A kill switch. Better if they could kill it without destroying a farm's worth of servers.
physics computers electricity electromagnetism data-storage
physics computers electricity electromagnetism data-storage
New contributor
New contributor
edited Nov 27 at 19:40
New contributor
asked Nov 27 at 14:17
John S.
5817
5817
New contributor
New contributor
Comments are not for extended discussion; this conversation has been moved to chat.
– L.Dutch♦
Nov 27 at 23:50
1
To clarify, you're asking about a single server farm, not all of them? ( Google undoubtedly locates their servers in various physical locations. Are you just wanting to take out one farm it all?). That's also not to mention backup/redundant servers.
– BruceWayne
Nov 28 at 0:55
1
Sometimes I feel like worldbuilding.SE is full of terrorists who are trying to crowdsource the plans for their evil deeds...
– Kapten-N
Nov 28 at 7:37
Well, you could replace the moon with a magnetar. That would probably kill everyone, but would wipe every hard drive in the world and would leave buildings and physical servers intact.
– forest
Nov 28 at 10:17
add a comment |
Comments are not for extended discussion; this conversation has been moved to chat.
– L.Dutch♦
Nov 27 at 23:50
1
To clarify, you're asking about a single server farm, not all of them? ( Google undoubtedly locates their servers in various physical locations. Are you just wanting to take out one farm it all?). That's also not to mention backup/redundant servers.
– BruceWayne
Nov 28 at 0:55
1
Sometimes I feel like worldbuilding.SE is full of terrorists who are trying to crowdsource the plans for their evil deeds...
– Kapten-N
Nov 28 at 7:37
Well, you could replace the moon with a magnetar. That would probably kill everyone, but would wipe every hard drive in the world and would leave buildings and physical servers intact.
– forest
Nov 28 at 10:17
Comments are not for extended discussion; this conversation has been moved to chat.
– L.Dutch♦
Nov 27 at 23:50
Comments are not for extended discussion; this conversation has been moved to chat.
– L.Dutch♦
Nov 27 at 23:50
1
1
To clarify, you're asking about a single server farm, not all of them? ( Google undoubtedly locates their servers in various physical locations. Are you just wanting to take out one farm it all?). That's also not to mention backup/redundant servers.
– BruceWayne
Nov 28 at 0:55
To clarify, you're asking about a single server farm, not all of them? ( Google undoubtedly locates their servers in various physical locations. Are you just wanting to take out one farm it all?). That's also not to mention backup/redundant servers.
– BruceWayne
Nov 28 at 0:55
1
1
Sometimes I feel like worldbuilding.SE is full of terrorists who are trying to crowdsource the plans for their evil deeds...
– Kapten-N
Nov 28 at 7:37
Sometimes I feel like worldbuilding.SE is full of terrorists who are trying to crowdsource the plans for their evil deeds...
– Kapten-N
Nov 28 at 7:37
Well, you could replace the moon with a magnetar. That would probably kill everyone, but would wipe every hard drive in the world and would leave buildings and physical servers intact.
– forest
Nov 28 at 10:17
Well, you could replace the moon with a magnetar. That would probably kill everyone, but would wipe every hard drive in the world and would leave buildings and physical servers intact.
– forest
Nov 28 at 10:17
add a comment |
6 Answers
6
active
oldest
votes
up vote
14
down vote
accepted
An EMP is probably not the right mechanism here - it will almost certainly result in large amounts of the precious smoke escaping from the sensitive electronics in the servers (and drives) but assuming it's a typical google data center then the bulk of the data is going to be stored on spinning rust and therefore will likely survive. It will be difficult, expensive and time consuming to recover since you'll need specialist forensics experts working on it though so this might be "good enough" for your purposes.
What you want is a pulse degausser - basically these create a rapidly alternating, incredibly powerful magnetic field that demagnetizes the drive platters rendering it an unrecoverable paperweight. The drives will have to be replaced afterwards (technically the manufacturer could recreate the servo track to make the drive re-usable but it's probably be cheaper just to buy new drives!) but the majority of the other components should survive. This though does have the opposite problem to the EMP idea - SSD drives and other flash-storage technology will shrug it off so you'll need to have an alternative strategy in place for those.
If we're into the realms of money being no object then a bespoke setup where each SSD was mounted in a modified version of a crusher like this would do the job - again the drives will be toast but there's very few other ways to destroy an SSD securely in rapid fashion, and 9 secs is going to take some serious beating.
Edit: Just seen an update from the OP on criteria.
What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged.
If secrecy surrounding at least the existence of the "fail safe" hardware prior to the "wipe" is required then the degausser option would still work - build it into the frame of the racking, sure it'll look a bit more robust than your average server rack but the owners could fob any questions off as it being for "Earthquake hardening" or something. Obviously post-wipe anyone with access to the drives is going to know what happened - a complete lack of data and the telltale demise of the servo track is a dead give away that the drive has been degaussed.
It does make any SSD drives more difficult to deal with though - crusher devices aren't exactly svelte and most techs are going to wonder why the "drive enclosure" for each SSD drive is a 12" or so tall. So for this I'd suggest a slightly different approach:
Have all data on the SSD drives be encrypted with something along the lines of AES, keep the key for that encryption on a separate drive that you keep out of the path of the day to day techs that is located in a crusher. When the fail safe is triggered you have key drive crushed at the same time as terminating power to any systems with the key in memory.
With the key gone the SSDs are left perfectly intact (saves on your BCDR budget a little bit :P ) but the data is, to all intents and purposes lost.
If you're wanting to use the EMP for The Rule of Cool you could have that take out the systems that have the key in memory if you want :)
So would it be possible to build a big enough pulse degausser to affect an entire data storage center? If the degausser were to run, followed by an EMP to take out solid state storage, it would effectively wipe all data on site?
– John S.
Nov 27 at 16:17
What you really want is some electromagnetic noise that tricks the firmware into thinking a write function is being requested.
– nzaman
Nov 27 at 16:18
2
@JohnSiskar theoretically yes - although it would probably make more sense to have multiple smaller ones that were all triggered simultaneously. Imagine the SAN units/drive enclosures essentially mounted in MRI machines and you're getting the gist. I still wouldn't bother with the EMP though - the collateral damage to pretty much everything electronic in the vicinity would be extreme and you still aren't guaranteeing total data loss. Crushers seem the more efficient option.
– motosubatsu
Nov 27 at 16:35
1
@motosubatsu Thanks so much for this. It is the solution to my problem. I love that about worldbuilding, so often the question you have is the wrong question, the answer something you hadn't even realized you needed. :)
– John S.
Nov 27 at 17:25
1
"Encrypt then delete key" is a system already in use in place of the old "write 0s ten times" disk erase strategy. This scaled-up version would work well.
– Elia
Nov 27 at 19:08
|
show 4 more comments
up vote
9
down vote
Small and easy!
Every piece of data stored in Google is actually split into multiple chunks. Each chunk is encrypted using a different key!
That's a lot of keys? How are they managed? Well, there are Key Management Servers (KMS) that take all those keys and encrypt them to ensure they are safe. Of course, the keys used to encrypt these keys also need to be encrypted. This goes until you get to the Root KMS key. This key exists on only a few machines in the datacenter... and if you can take all of these out (keep in mind, resiliency is built in by design) then nobody can decrypt any keys underneath it! All the data is still there, but meaningless and lost forever. This is similar to @nzaman's thinking, but already done, only requires impacting a few machines rather than every machine.
So it's not the size of the bomb, but the location(s) that makes all the difference.
https://cloud.google.com/security/encryption-at-rest/default-encryption/
Or is it?
Google isn't silly enough to trust all its keys to a single data center. There is always a risk that some massive power outage etc. would compromise the keys (stored in memory only) and losing that data would be disastrous. So there are two fail safes:
The Root KMS Master Key Distributor, essentially a P2P backup with other datacenters:
Root KMS in turn has its own root key, called the root KMS master key, which is also AES256 and is stored in a peer-to-peer infrastructure, the root KMS master key distributor, which replicates these keys globally. The root KMS master key distributor only holds the keys in RAM on the same dedicated machines as Root KMS
And the Safes:
To address the scenario where all instances of the root KMS master key distributor restart simultaneously, the root KMS master key is also backed up on secure hardware devices stored in physical safes in highly secured areas in two physically separated, global Google locations. This backup would be needed only if all distributor instances were to go down at once; for example, in a global restart. Fewer than 20 Google employees are able to access these safes.
Now whether or not these backup strategies exist in your world, or can be avoided through other means (e.g. more than one 'bomb') is entirely up to your world-building.
1
Huge portions of the Google DB have no reason to be encrypted. It is not a trade secret that the search crawler scanned diy.stackexchange.com/tour and stored a cache of it. Do they really encrypt all of that?
– Harper
Nov 27 at 20:12
This is wonderfully brilliant, and again would not work in my case. But it's also a horribly interesting fact, notwithstanding usability. Thanks for sharing it, I find the idea to be awesome. :)
– John S.
Nov 27 at 20:37
1
@Harper I presume yes. To give you an idea, that entire process that is described happens every single time you open an email, or every single time a google doc is autosaved. Google takes security very seriously and builds it into the foundation of the tools they use (e.g. at the data layer itself). Their database tool simply wouldn't have an option to not encrypt the data... it's not something that can be turned off.
– NPSF3000
Nov 27 at 21:18
1
@JohnS. My pleasure, hope your world comes together nicely.
– NPSF3000
Nov 27 at 21:19
@forest formatting issue, the 4 was a footnote reference. Fixed.
– NPSF3000
Nov 28 at 13:39
add a comment |
up vote
5
down vote
As others discuss, EMP will damage the machines that access the data, but not the data. You mention that your forces are owners or insiders, who can alter the design to suit, but need to conceal it from line staff who work there. I cannot see a non-detectable way to wipe the software without damaging your hardware. If you use internal malware, and even one backup survives, you are exposed. But to an evil genius, hardware is cheap. Let insurance buy you new hardware and that opens you up to many options. For instnace
Plain old fire
Burn the place to the ground. Simple as that. Build the place out of materials that'll squeak by the fire codes, but then store things in there that will subtly add to and sustain the conflagration. By "subtle" I mean that what fuels office building fires is the office trim and file cabinets full of paper. The trim can be made endothermic, the paper cannot. What's ironic about 9/11 is the jet fuel flashed off quickly, the paper sustained the fire.
Likewise, start the fire with liquid or gaseous fuel and let the paper finish the job. Of course you'd need to either damage the sprinkler system or subvert it to your purposes. Also strive to use more burnable materials where excusable, such as you will want servers with plastic cases, and SSD rather than HDD.
Lastly you'll want what steel mills and refineries actually do need: fire-truck-proof gates. Those industries don't want the F.D. yokels charging in and throwing a water hose on a hot metal bottle or sodium fire. In your case you are worried about terror attacks, or some other thing. And make sure to have onsite security doors which get F.D. Approval, but then frustrate their entry. Just build your building to make it hard to fight fires in, so they switch to 'let it burn out' and containment.
Locating in an unfinished nuclear reactor would be a fun way to do it.
Love the imagination, doesn't work in the context of my story, but love it nonetheless. :)
– John S.
Nov 27 at 18:53
2
Or "upgrade" the sprinkler systems to a new fire retardant that needs to be stored in a massive tank in the server farm. Then accidentally fill it full of some highly flammable fuels, instead of actual fire retardants :)
– X-27
Nov 27 at 23:44
2
@X-27 sure. Or I was just thinking, you have a diesel fire pump, the fire sprinkler lines are red because of the Fire Code, the diesel fuel lines are red because of the Mechanical Code or somesuch, tragic plumbing error.
– Harper
Nov 27 at 23:57
1
And remember, you can't put too much water in a nuclear reactor.
– manassehkatz
Nov 28 at 2:47
1
Fire is not actually as effective as you'd expect, you need to get up to some serious temperatures (probably 800-1000K to be sure). Given the OP's requirement for speed you're going to need to get the drive platters up to those temps quickly, Thermite works but deploying it might be tricky
– motosubatsu
Nov 28 at 9:36
|
show 2 more comments
up vote
5
down vote
Sound Waves!
Years ago, I was working on some laptop theft prevention software, which in addition to a hardware alarm would activate a laptop's speaker. I had an odd situation on a particular Asus Aspire One laptop where the software would work great while testing, but every time a demo was done, it would BSOD. Naturally, this didn't make my client very happy. I worked on the problem for months trying to figure out what was going on. The problem never occurred on my laptop, only his demo laptop. I ended up buying extra laptops to test. At one point we went to go buy a second of that type of laptop. While looking up the model number, I found an article stating a particular fatal flaw. The speaker was mounted directly on top of the hard drive. At a particular frequency range, the hard drive would basically wreck the data coming out of it, which caused Windows to crash because swapfile was in-use because this laptop also had very little RAM. That particular frequency range happened to be almost exactly what I had chosen for my alarm sound effect. When I would test, the volume was way way down. But, during demos, we would crank it up and almost guarantee a blue screen.
This problem made me start to wonder about other places this could be a problem. Around the same time, some guy posted a video of himself screaming at a hard drive array, causing read latency to increase: https://www.youtube.com/watch?v=tDacjrSCeq4
Since then, I've thought that a particularly crafty malicious hacker could build a device with a bunch of ultrasonic transducers, and hidden somehow in a rack in a cage in a datacenter. With ultrasonic, while you can't hear it, you can create an interference pattern by using two lower frequencies that is in the range of what you need, while retaining the property of having an extremely directional beam. Your device could effectively shoot sonic lasers at particular devices in the datacenter, causing glitches-to-complete-failures in magnetic hard drives, all while not being heard by humans unless they were in the direct path at the time.
Most of the drives for bulk storage are magnetic, with read/write heads barely floating above the drive platters spinning crazy fast underneath. Everything has to be perfectly in balance.
SSDs don't have this trouble, so this method won't apply to them.
New contributor
1
This won't destroy the data, just make read operations fail while the sonic "laser" is on. Anyway, +1 for creativity.
– Guntram Blohm
Nov 28 at 6:11
@GuntramBlohm Ah, to clarify I figured since we're talking EMP levels here to begin with, you could get some very powerful transducers to totally wreck things. However, reconsidering this today, I now realize you would basically destroy the entire facility if you could somehow push that much energy through such a device. :-)
– Brad
Nov 28 at 14:08
add a comment |
up vote
4
down vote
It isn't only a question of how big, but a question of where. EMP on the data bus is a different beast from EMP in the power supply, which is a different beast from a simple EMP generator within the room but not connected to anything.
Case 1: EMP in the data buses
The most difficult to create, but also the most devastating. You are supplying a high voltage in the cables through which the data passes. Assuming no intermediate devices burn out, your EMP will make it all the way to the storage drives and work their damage there. No guarantees that nothing can be recovered by forensic examination of the disks, but the disks themselves will be unusable.
Getting a high voltage pulse into those cables is near impossible, unless you have physical access to them, as the cables are shielded against EMP for precisely this reason. If you do have physical access, introducing malware or something similar is a better way to do things. If you're a three-letter agency, for instance, you'll find it more rewarding to spy on people's data, rather than deleting it.
Case 2: EMP in the power supply
By far easier than case 1 and far more likely to happen, given exposed transmission lines. Except that any data centre will have decoupling and power conditioning systems before the power supply gets anywhere near the data, to ensure no unwanted spikes or dips get through. Unless you're actually inside the data centre,or better yet, inside the actual server room, in case they have a final redundant decoupling system, you're not likely to do much damage.
Assuming everything goes your way, and you do successfully set off an EMP after bypassing all the protections, you'll destroy the servers, but probably not most of the data. They will need forensics to recover it, but it can be recovered. The electronics will be slagged, however, so the servers will probably be unusable.
Case 3: EMP inside the server room
Comparatively, the easiest way to cause some damage, but overall likelihood of causing less damage than a successful attempt at Case 1 or 2. Your EMP will weaken with the square of distance, so a million volts or so will be needed to get the whole room, given that the server enclosures will act as Faraday cages and protect their insides. With less voltage, you'll destroy everything nearby, with damage tapering off as you go further from ground zero. This depends on the geometry of the room and the kind of earthing in place. A rectangular room will take less damage than a square room; an L-shape will take less damage, unless the EMP goes off in the crook of the L.
I really like your answer. What you said about the Faraday cage is very important, because almost every mass storage device is encased in a metal shell. The actual data most likely will not be wiped out by a EMP. The electronics sitting outside the Faraday cage will be destroyed, however, unless those mass storage devices are sitting inside a metal RAID array enclosure. Then the only exposed wiring would be the power cord and data cable.
– hyperion4
Nov 27 at 15:56
So assuming you have full access to the entire server facility, unlimited resources, access and time, putting them into the data bus would work. Would this also destroy all the servers themselves, as they pass data through the bus, or only the storage devices? What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged. Either way, helpful answer, if not exactly what I need. :)
– John S.
Nov 27 at 16:11
1
@JohnSiskar: It depends on the size of the spike. A series of low voltage spikes could corrupt the data and leave the hardware unharmed. A large spike would fry the electronics and leave the data unaffected. The problem with random effects is that you can't guarantee the outcome
– nzaman
Nov 27 at 16:15
1
@JohnS The data bus has some built in error correction. Data centers use fibre channel or iSCSI though, which means OPTICAL cables, which are immune to electromagnetic interference,so the only vulnerable points would be the metal connectors holding the optical cables to the drive array and CPU motherboards. However, I doubt most computer enclosures act as ideal Faraday cages so the CPUs would fry before the hard drives lose data.
– hyperion4
Nov 28 at 1:29
add a comment |
up vote
2
down vote
Use paper stickers with housekeeping information to keep track of your disk drives!
How would it help? Well, the stickers can have flat coils inside, just like those stickers that make detectors at shop exits beep at you. The coils can do the EMP and degaussing stuff, while also doubling as an antenna for a small control chip. That tiny low-power chip, and the coil, can be powered from a relatively small capacitor, which can be hidden under the sticker too. (Or inside the case, in case of SSDs, as those rarely have big enough cavities on the outside to hide the capacitor in.) The capacitor is absolutely essential in the case that the disk is completely disconnected for maintenance or other reasons when the kill-switch is triggered. It is recharged when the disk is online.
Sticking that coil right to the disk's circuit board should allow for small enough capacitor to kill whatever chips are on the other side with EMP, or to degauss the platters. For SSDs that extra capacitor can also be connected directly to the board instead, frying all the flash chips as soon as the signal comes. Maybe that small controller could also be connected directly to the motor and the heads of an HDD, making it literally scratch out all the data by slowly spinning the platters under unparked heads.
Add a powerful enough wireless transmitter to cover the whole complex, and a big red button (or a small gray one) for the trigger, and you are set! Keep in mind, though, that if someone tears off a sticker and notices a capacitor that's not connected to anything, they might suspect something and take a closer look at the sticker... With that caveat in mind, I think the idea is quite plausible. Someone might have to figure out exactly how big the capacitor has to actually be, but at least for frying flash in SSDs you most definitely can buy powerful enough yet really small caps.
My original idea follows:
Software could, and would in the context of the story, be found and purged.
What about embedded software? Modern computers are very damn smart. Every sizable component has a CPU, be it a network adapter or a microSD card.
Intel AMT allows you to connect to a server remotely and work on it like it's in front of you: a display, a keyboard, you can even "plug in" your hard disk into it over the network. And the best part is, all this works as soon as you press the power button (some of it even before that), and it is completely out-of-band. That last bit means that any software working on this server will never see any AMT traffic, and it will think that you've actually opened up the case and attached that HDD.
Despite having all that functionality, AMT works almost entirely on the motherboard itself, doesn't touch the main CPU or RAM, and is almost invisible to the "main" system. It's code is very obscure, extremely platform-specific and proprietary. Only some very smart hackers managed to get into it (and find a few glaring security holes...), under the normal circumstances no one will ever touch it in any way other than through the official client software from Intel.
Every HDD and SSD has an embedded controller, too. Wiping an SSD "from the inside" is as simple as "forgetting" where the index for all of its flash memory is, maybe wiping that relatively small index beforehand for good measure. And on HDD you can just slow down the platters enough for the heads to land on them and dig trenches all over the surface. (The heads are too weak to magnetically damage the data quickly enough, so physically damaging the surface is the only way.)
All the network hardware also has embedded processors, even the "really" embedded ones in case of bigger devices that are like normal computers themselves on the inside.
What I'm getting at is, most people don't even realize that their microSD card may well be more computationally powerful than a PC from late 90s! No one ever really looks inside those embedded chips. Oftentimes you cannot even read the firmware from them, only flash the updates. (And thus their security is severely lacking oftentimes, except the "Security through Obscurity" kind.)
If some kind of backdoor is installed on that level, I doubt that anyone will ever notice it. At least not until it's exploited and forensics start digging into the chips. No "normal" software will be able to detect that something's wrong, you'd have to take the device apart and dig in with a JTAG debugger to even have a chance.
Let's say that one of the routers in the datacenter receives a malformed packet. It looks like it's a normal packet that got (unnaturally severely) corrupted in transit. Normally, it would be silently dropped, and higher level protocol, like TCP, will request retransmission. Suddenly, the router broadcasts that same packet over all its connections, and then immediately "dies", maybe requiring a firmware recovery procedure to continue functioning. Every server that receives the packet suddenly crashes due to CPU voltage dropping below acceptable minimum, and its disks experience catastrophic firmware failure that destroys all the data in a matter of seconds. A few more seconds later, the "smart" power supply infrastructure, which also received the packet of death, cuts the power to the whole complex. And perimeter routers just receive and drop the packet as they should, not a single bit of suspicious data gets outside.
In just 10 seconds or so, the datacenter inexplicably goes from perfectly fine and healthy to totally blacked out and dead. All the networking infrastructure is lacking any firmware to even work. All the data is lost, either in unintelligible fragments randomly scattered across several flash chips in each SSD, or literally scattered all over the insides of HDDs.
No one has any clue as to what has happened. Even if someone figures out later that the firmware of almost everything in the complex had peculiar bugs that just so happened to act together in such devastating manner, it can still look like it all was an accident. Since there are no traces of the packet that caused the whole mess, the only way someone might figure out that it was malicious is by contacting HDD vendors and finding out that the firmware slightly differs from what should have been there, but even that would be practically impossible to say for sure, due to how much things change internally during product life cycle.
And in that last bit lies the catch. That 'small team' of yours will have to reverse engineer the firmware of every HDD, SSD, motherboard, network card and router in the datacenter, plus the smart power supply system. There likely will only be just a few kinds of each component, since they are ordered in bulk, and the slight variations in hardware revisions should not be much of a problem, but that's still a huge load of work, and it will take time.
Plus, if any machine just so happens to be offline, as in "completely disconnected", its data will survive. The same goes for any disks that happen to be taken out at the moment. The only "safe" solution to that would be to have a small autonomously powered wireless bug on every HDD that will, when triggered remotely, turn on the disk, if it was offline, and order it to go kill itself. Or make it discharge a capacitor into a small flat coil glued to the disk. (Like those stickers that make detectors at shop exits beep at you. It can even have some housekeeping information printed on it, so that there is a reason for it to be there. No one needs to know that there is a coil inside the sticker. The capacitor will still be noticeable, though, unless you hide it under that sticker.)
Or, you know, you could just kill it with fire. But that is outside of my area of expertise.
New contributor
Wow, that is amazingly well thought out. Thank you for the input! :)
– John S.
Nov 28 at 13:09
add a comment |
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
accepted
An EMP is probably not the right mechanism here - it will almost certainly result in large amounts of the precious smoke escaping from the sensitive electronics in the servers (and drives) but assuming it's a typical google data center then the bulk of the data is going to be stored on spinning rust and therefore will likely survive. It will be difficult, expensive and time consuming to recover since you'll need specialist forensics experts working on it though so this might be "good enough" for your purposes.
What you want is a pulse degausser - basically these create a rapidly alternating, incredibly powerful magnetic field that demagnetizes the drive platters rendering it an unrecoverable paperweight. The drives will have to be replaced afterwards (technically the manufacturer could recreate the servo track to make the drive re-usable but it's probably be cheaper just to buy new drives!) but the majority of the other components should survive. This though does have the opposite problem to the EMP idea - SSD drives and other flash-storage technology will shrug it off so you'll need to have an alternative strategy in place for those.
If we're into the realms of money being no object then a bespoke setup where each SSD was mounted in a modified version of a crusher like this would do the job - again the drives will be toast but there's very few other ways to destroy an SSD securely in rapid fashion, and 9 secs is going to take some serious beating.
Edit: Just seen an update from the OP on criteria.
What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged.
If secrecy surrounding at least the existence of the "fail safe" hardware prior to the "wipe" is required then the degausser option would still work - build it into the frame of the racking, sure it'll look a bit more robust than your average server rack but the owners could fob any questions off as it being for "Earthquake hardening" or something. Obviously post-wipe anyone with access to the drives is going to know what happened - a complete lack of data and the telltale demise of the servo track is a dead give away that the drive has been degaussed.
It does make any SSD drives more difficult to deal with though - crusher devices aren't exactly svelte and most techs are going to wonder why the "drive enclosure" for each SSD drive is a 12" or so tall. So for this I'd suggest a slightly different approach:
Have all data on the SSD drives be encrypted with something along the lines of AES, keep the key for that encryption on a separate drive that you keep out of the path of the day to day techs that is located in a crusher. When the fail safe is triggered you have key drive crushed at the same time as terminating power to any systems with the key in memory.
With the key gone the SSDs are left perfectly intact (saves on your BCDR budget a little bit :P ) but the data is, to all intents and purposes lost.
If you're wanting to use the EMP for The Rule of Cool you could have that take out the systems that have the key in memory if you want :)
So would it be possible to build a big enough pulse degausser to affect an entire data storage center? If the degausser were to run, followed by an EMP to take out solid state storage, it would effectively wipe all data on site?
– John S.
Nov 27 at 16:17
What you really want is some electromagnetic noise that tricks the firmware into thinking a write function is being requested.
– nzaman
Nov 27 at 16:18
2
@JohnSiskar theoretically yes - although it would probably make more sense to have multiple smaller ones that were all triggered simultaneously. Imagine the SAN units/drive enclosures essentially mounted in MRI machines and you're getting the gist. I still wouldn't bother with the EMP though - the collateral damage to pretty much everything electronic in the vicinity would be extreme and you still aren't guaranteeing total data loss. Crushers seem the more efficient option.
– motosubatsu
Nov 27 at 16:35
1
@motosubatsu Thanks so much for this. It is the solution to my problem. I love that about worldbuilding, so often the question you have is the wrong question, the answer something you hadn't even realized you needed. :)
– John S.
Nov 27 at 17:25
1
"Encrypt then delete key" is a system already in use in place of the old "write 0s ten times" disk erase strategy. This scaled-up version would work well.
– Elia
Nov 27 at 19:08
|
show 4 more comments
up vote
14
down vote
accepted
An EMP is probably not the right mechanism here - it will almost certainly result in large amounts of the precious smoke escaping from the sensitive electronics in the servers (and drives) but assuming it's a typical google data center then the bulk of the data is going to be stored on spinning rust and therefore will likely survive. It will be difficult, expensive and time consuming to recover since you'll need specialist forensics experts working on it though so this might be "good enough" for your purposes.
What you want is a pulse degausser - basically these create a rapidly alternating, incredibly powerful magnetic field that demagnetizes the drive platters rendering it an unrecoverable paperweight. The drives will have to be replaced afterwards (technically the manufacturer could recreate the servo track to make the drive re-usable but it's probably be cheaper just to buy new drives!) but the majority of the other components should survive. This though does have the opposite problem to the EMP idea - SSD drives and other flash-storage technology will shrug it off so you'll need to have an alternative strategy in place for those.
If we're into the realms of money being no object then a bespoke setup where each SSD was mounted in a modified version of a crusher like this would do the job - again the drives will be toast but there's very few other ways to destroy an SSD securely in rapid fashion, and 9 secs is going to take some serious beating.
Edit: Just seen an update from the OP on criteria.
What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged.
If secrecy surrounding at least the existence of the "fail safe" hardware prior to the "wipe" is required then the degausser option would still work - build it into the frame of the racking, sure it'll look a bit more robust than your average server rack but the owners could fob any questions off as it being for "Earthquake hardening" or something. Obviously post-wipe anyone with access to the drives is going to know what happened - a complete lack of data and the telltale demise of the servo track is a dead give away that the drive has been degaussed.
It does make any SSD drives more difficult to deal with though - crusher devices aren't exactly svelte and most techs are going to wonder why the "drive enclosure" for each SSD drive is a 12" or so tall. So for this I'd suggest a slightly different approach:
Have all data on the SSD drives be encrypted with something along the lines of AES, keep the key for that encryption on a separate drive that you keep out of the path of the day to day techs that is located in a crusher. When the fail safe is triggered you have key drive crushed at the same time as terminating power to any systems with the key in memory.
With the key gone the SSDs are left perfectly intact (saves on your BCDR budget a little bit :P ) but the data is, to all intents and purposes lost.
If you're wanting to use the EMP for The Rule of Cool you could have that take out the systems that have the key in memory if you want :)
So would it be possible to build a big enough pulse degausser to affect an entire data storage center? If the degausser were to run, followed by an EMP to take out solid state storage, it would effectively wipe all data on site?
– John S.
Nov 27 at 16:17
What you really want is some electromagnetic noise that tricks the firmware into thinking a write function is being requested.
– nzaman
Nov 27 at 16:18
2
@JohnSiskar theoretically yes - although it would probably make more sense to have multiple smaller ones that were all triggered simultaneously. Imagine the SAN units/drive enclosures essentially mounted in MRI machines and you're getting the gist. I still wouldn't bother with the EMP though - the collateral damage to pretty much everything electronic in the vicinity would be extreme and you still aren't guaranteeing total data loss. Crushers seem the more efficient option.
– motosubatsu
Nov 27 at 16:35
1
@motosubatsu Thanks so much for this. It is the solution to my problem. I love that about worldbuilding, so often the question you have is the wrong question, the answer something you hadn't even realized you needed. :)
– John S.
Nov 27 at 17:25
1
"Encrypt then delete key" is a system already in use in place of the old "write 0s ten times" disk erase strategy. This scaled-up version would work well.
– Elia
Nov 27 at 19:08
|
show 4 more comments
up vote
14
down vote
accepted
up vote
14
down vote
accepted
An EMP is probably not the right mechanism here - it will almost certainly result in large amounts of the precious smoke escaping from the sensitive electronics in the servers (and drives) but assuming it's a typical google data center then the bulk of the data is going to be stored on spinning rust and therefore will likely survive. It will be difficult, expensive and time consuming to recover since you'll need specialist forensics experts working on it though so this might be "good enough" for your purposes.
What you want is a pulse degausser - basically these create a rapidly alternating, incredibly powerful magnetic field that demagnetizes the drive platters rendering it an unrecoverable paperweight. The drives will have to be replaced afterwards (technically the manufacturer could recreate the servo track to make the drive re-usable but it's probably be cheaper just to buy new drives!) but the majority of the other components should survive. This though does have the opposite problem to the EMP idea - SSD drives and other flash-storage technology will shrug it off so you'll need to have an alternative strategy in place for those.
If we're into the realms of money being no object then a bespoke setup where each SSD was mounted in a modified version of a crusher like this would do the job - again the drives will be toast but there's very few other ways to destroy an SSD securely in rapid fashion, and 9 secs is going to take some serious beating.
Edit: Just seen an update from the OP on criteria.
What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged.
If secrecy surrounding at least the existence of the "fail safe" hardware prior to the "wipe" is required then the degausser option would still work - build it into the frame of the racking, sure it'll look a bit more robust than your average server rack but the owners could fob any questions off as it being for "Earthquake hardening" or something. Obviously post-wipe anyone with access to the drives is going to know what happened - a complete lack of data and the telltale demise of the servo track is a dead give away that the drive has been degaussed.
It does make any SSD drives more difficult to deal with though - crusher devices aren't exactly svelte and most techs are going to wonder why the "drive enclosure" for each SSD drive is a 12" or so tall. So for this I'd suggest a slightly different approach:
Have all data on the SSD drives be encrypted with something along the lines of AES, keep the key for that encryption on a separate drive that you keep out of the path of the day to day techs that is located in a crusher. When the fail safe is triggered you have key drive crushed at the same time as terminating power to any systems with the key in memory.
With the key gone the SSDs are left perfectly intact (saves on your BCDR budget a little bit :P ) but the data is, to all intents and purposes lost.
If you're wanting to use the EMP for The Rule of Cool you could have that take out the systems that have the key in memory if you want :)
An EMP is probably not the right mechanism here - it will almost certainly result in large amounts of the precious smoke escaping from the sensitive electronics in the servers (and drives) but assuming it's a typical google data center then the bulk of the data is going to be stored on spinning rust and therefore will likely survive. It will be difficult, expensive and time consuming to recover since you'll need specialist forensics experts working on it though so this might be "good enough" for your purposes.
What you want is a pulse degausser - basically these create a rapidly alternating, incredibly powerful magnetic field that demagnetizes the drive platters rendering it an unrecoverable paperweight. The drives will have to be replaced afterwards (technically the manufacturer could recreate the servo track to make the drive re-usable but it's probably be cheaper just to buy new drives!) but the majority of the other components should survive. This though does have the opposite problem to the EMP idea - SSD drives and other flash-storage technology will shrug it off so you'll need to have an alternative strategy in place for those.
If we're into the realms of money being no object then a bespoke setup where each SSD was mounted in a modified version of a crusher like this would do the job - again the drives will be toast but there's very few other ways to destroy an SSD securely in rapid fashion, and 9 secs is going to take some serious beating.
Edit: Just seen an update from the OP on criteria.
What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged.
If secrecy surrounding at least the existence of the "fail safe" hardware prior to the "wipe" is required then the degausser option would still work - build it into the frame of the racking, sure it'll look a bit more robust than your average server rack but the owners could fob any questions off as it being for "Earthquake hardening" or something. Obviously post-wipe anyone with access to the drives is going to know what happened - a complete lack of data and the telltale demise of the servo track is a dead give away that the drive has been degaussed.
It does make any SSD drives more difficult to deal with though - crusher devices aren't exactly svelte and most techs are going to wonder why the "drive enclosure" for each SSD drive is a 12" or so tall. So for this I'd suggest a slightly different approach:
Have all data on the SSD drives be encrypted with something along the lines of AES, keep the key for that encryption on a separate drive that you keep out of the path of the day to day techs that is located in a crusher. When the fail safe is triggered you have key drive crushed at the same time as terminating power to any systems with the key in memory.
With the key gone the SSDs are left perfectly intact (saves on your BCDR budget a little bit :P ) but the data is, to all intents and purposes lost.
If you're wanting to use the EMP for The Rule of Cool you could have that take out the systems that have the key in memory if you want :)
edited Nov 27 at 16:57
answered Nov 27 at 15:38
motosubatsu
1,9252414
1,9252414
So would it be possible to build a big enough pulse degausser to affect an entire data storage center? If the degausser were to run, followed by an EMP to take out solid state storage, it would effectively wipe all data on site?
– John S.
Nov 27 at 16:17
What you really want is some electromagnetic noise that tricks the firmware into thinking a write function is being requested.
– nzaman
Nov 27 at 16:18
2
@JohnSiskar theoretically yes - although it would probably make more sense to have multiple smaller ones that were all triggered simultaneously. Imagine the SAN units/drive enclosures essentially mounted in MRI machines and you're getting the gist. I still wouldn't bother with the EMP though - the collateral damage to pretty much everything electronic in the vicinity would be extreme and you still aren't guaranteeing total data loss. Crushers seem the more efficient option.
– motosubatsu
Nov 27 at 16:35
1
@motosubatsu Thanks so much for this. It is the solution to my problem. I love that about worldbuilding, so often the question you have is the wrong question, the answer something you hadn't even realized you needed. :)
– John S.
Nov 27 at 17:25
1
"Encrypt then delete key" is a system already in use in place of the old "write 0s ten times" disk erase strategy. This scaled-up version would work well.
– Elia
Nov 27 at 19:08
|
show 4 more comments
So would it be possible to build a big enough pulse degausser to affect an entire data storage center? If the degausser were to run, followed by an EMP to take out solid state storage, it would effectively wipe all data on site?
– John S.
Nov 27 at 16:17
What you really want is some electromagnetic noise that tricks the firmware into thinking a write function is being requested.
– nzaman
Nov 27 at 16:18
2
@JohnSiskar theoretically yes - although it would probably make more sense to have multiple smaller ones that were all triggered simultaneously. Imagine the SAN units/drive enclosures essentially mounted in MRI machines and you're getting the gist. I still wouldn't bother with the EMP though - the collateral damage to pretty much everything electronic in the vicinity would be extreme and you still aren't guaranteeing total data loss. Crushers seem the more efficient option.
– motosubatsu
Nov 27 at 16:35
1
@motosubatsu Thanks so much for this. It is the solution to my problem. I love that about worldbuilding, so often the question you have is the wrong question, the answer something you hadn't even realized you needed. :)
– John S.
Nov 27 at 17:25
1
"Encrypt then delete key" is a system already in use in place of the old "write 0s ten times" disk erase strategy. This scaled-up version would work well.
– Elia
Nov 27 at 19:08
So would it be possible to build a big enough pulse degausser to affect an entire data storage center? If the degausser were to run, followed by an EMP to take out solid state storage, it would effectively wipe all data on site?
– John S.
Nov 27 at 16:17
So would it be possible to build a big enough pulse degausser to affect an entire data storage center? If the degausser were to run, followed by an EMP to take out solid state storage, it would effectively wipe all data on site?
– John S.
Nov 27 at 16:17
What you really want is some electromagnetic noise that tricks the firmware into thinking a write function is being requested.
– nzaman
Nov 27 at 16:18
What you really want is some electromagnetic noise that tricks the firmware into thinking a write function is being requested.
– nzaman
Nov 27 at 16:18
2
2
@JohnSiskar theoretically yes - although it would probably make more sense to have multiple smaller ones that were all triggered simultaneously. Imagine the SAN units/drive enclosures essentially mounted in MRI machines and you're getting the gist. I still wouldn't bother with the EMP though - the collateral damage to pretty much everything electronic in the vicinity would be extreme and you still aren't guaranteeing total data loss. Crushers seem the more efficient option.
– motosubatsu
Nov 27 at 16:35
@JohnSiskar theoretically yes - although it would probably make more sense to have multiple smaller ones that were all triggered simultaneously. Imagine the SAN units/drive enclosures essentially mounted in MRI machines and you're getting the gist. I still wouldn't bother with the EMP though - the collateral damage to pretty much everything electronic in the vicinity would be extreme and you still aren't guaranteeing total data loss. Crushers seem the more efficient option.
– motosubatsu
Nov 27 at 16:35
1
1
@motosubatsu Thanks so much for this. It is the solution to my problem. I love that about worldbuilding, so often the question you have is the wrong question, the answer something you hadn't even realized you needed. :)
– John S.
Nov 27 at 17:25
@motosubatsu Thanks so much for this. It is the solution to my problem. I love that about worldbuilding, so often the question you have is the wrong question, the answer something you hadn't even realized you needed. :)
– John S.
Nov 27 at 17:25
1
1
"Encrypt then delete key" is a system already in use in place of the old "write 0s ten times" disk erase strategy. This scaled-up version would work well.
– Elia
Nov 27 at 19:08
"Encrypt then delete key" is a system already in use in place of the old "write 0s ten times" disk erase strategy. This scaled-up version would work well.
– Elia
Nov 27 at 19:08
|
show 4 more comments
up vote
9
down vote
Small and easy!
Every piece of data stored in Google is actually split into multiple chunks. Each chunk is encrypted using a different key!
That's a lot of keys? How are they managed? Well, there are Key Management Servers (KMS) that take all those keys and encrypt them to ensure they are safe. Of course, the keys used to encrypt these keys also need to be encrypted. This goes until you get to the Root KMS key. This key exists on only a few machines in the datacenter... and if you can take all of these out (keep in mind, resiliency is built in by design) then nobody can decrypt any keys underneath it! All the data is still there, but meaningless and lost forever. This is similar to @nzaman's thinking, but already done, only requires impacting a few machines rather than every machine.
So it's not the size of the bomb, but the location(s) that makes all the difference.
https://cloud.google.com/security/encryption-at-rest/default-encryption/
Or is it?
Google isn't silly enough to trust all its keys to a single data center. There is always a risk that some massive power outage etc. would compromise the keys (stored in memory only) and losing that data would be disastrous. So there are two fail safes:
The Root KMS Master Key Distributor, essentially a P2P backup with other datacenters:
Root KMS in turn has its own root key, called the root KMS master key, which is also AES256 and is stored in a peer-to-peer infrastructure, the root KMS master key distributor, which replicates these keys globally. The root KMS master key distributor only holds the keys in RAM on the same dedicated machines as Root KMS
And the Safes:
To address the scenario where all instances of the root KMS master key distributor restart simultaneously, the root KMS master key is also backed up on secure hardware devices stored in physical safes in highly secured areas in two physically separated, global Google locations. This backup would be needed only if all distributor instances were to go down at once; for example, in a global restart. Fewer than 20 Google employees are able to access these safes.
Now whether or not these backup strategies exist in your world, or can be avoided through other means (e.g. more than one 'bomb') is entirely up to your world-building.
1
Huge portions of the Google DB have no reason to be encrypted. It is not a trade secret that the search crawler scanned diy.stackexchange.com/tour and stored a cache of it. Do they really encrypt all of that?
– Harper
Nov 27 at 20:12
This is wonderfully brilliant, and again would not work in my case. But it's also a horribly interesting fact, notwithstanding usability. Thanks for sharing it, I find the idea to be awesome. :)
– John S.
Nov 27 at 20:37
1
@Harper I presume yes. To give you an idea, that entire process that is described happens every single time you open an email, or every single time a google doc is autosaved. Google takes security very seriously and builds it into the foundation of the tools they use (e.g. at the data layer itself). Their database tool simply wouldn't have an option to not encrypt the data... it's not something that can be turned off.
– NPSF3000
Nov 27 at 21:18
1
@JohnS. My pleasure, hope your world comes together nicely.
– NPSF3000
Nov 27 at 21:19
@forest formatting issue, the 4 was a footnote reference. Fixed.
– NPSF3000
Nov 28 at 13:39
add a comment |
up vote
9
down vote
Small and easy!
Every piece of data stored in Google is actually split into multiple chunks. Each chunk is encrypted using a different key!
That's a lot of keys? How are they managed? Well, there are Key Management Servers (KMS) that take all those keys and encrypt them to ensure they are safe. Of course, the keys used to encrypt these keys also need to be encrypted. This goes until you get to the Root KMS key. This key exists on only a few machines in the datacenter... and if you can take all of these out (keep in mind, resiliency is built in by design) then nobody can decrypt any keys underneath it! All the data is still there, but meaningless and lost forever. This is similar to @nzaman's thinking, but already done, only requires impacting a few machines rather than every machine.
So it's not the size of the bomb, but the location(s) that makes all the difference.
https://cloud.google.com/security/encryption-at-rest/default-encryption/
Or is it?
Google isn't silly enough to trust all its keys to a single data center. There is always a risk that some massive power outage etc. would compromise the keys (stored in memory only) and losing that data would be disastrous. So there are two fail safes:
The Root KMS Master Key Distributor, essentially a P2P backup with other datacenters:
Root KMS in turn has its own root key, called the root KMS master key, which is also AES256 and is stored in a peer-to-peer infrastructure, the root KMS master key distributor, which replicates these keys globally. The root KMS master key distributor only holds the keys in RAM on the same dedicated machines as Root KMS
And the Safes:
To address the scenario where all instances of the root KMS master key distributor restart simultaneously, the root KMS master key is also backed up on secure hardware devices stored in physical safes in highly secured areas in two physically separated, global Google locations. This backup would be needed only if all distributor instances were to go down at once; for example, in a global restart. Fewer than 20 Google employees are able to access these safes.
Now whether or not these backup strategies exist in your world, or can be avoided through other means (e.g. more than one 'bomb') is entirely up to your world-building.
1
Huge portions of the Google DB have no reason to be encrypted. It is not a trade secret that the search crawler scanned diy.stackexchange.com/tour and stored a cache of it. Do they really encrypt all of that?
– Harper
Nov 27 at 20:12
This is wonderfully brilliant, and again would not work in my case. But it's also a horribly interesting fact, notwithstanding usability. Thanks for sharing it, I find the idea to be awesome. :)
– John S.
Nov 27 at 20:37
1
@Harper I presume yes. To give you an idea, that entire process that is described happens every single time you open an email, or every single time a google doc is autosaved. Google takes security very seriously and builds it into the foundation of the tools they use (e.g. at the data layer itself). Their database tool simply wouldn't have an option to not encrypt the data... it's not something that can be turned off.
– NPSF3000
Nov 27 at 21:18
1
@JohnS. My pleasure, hope your world comes together nicely.
– NPSF3000
Nov 27 at 21:19
@forest formatting issue, the 4 was a footnote reference. Fixed.
– NPSF3000
Nov 28 at 13:39
add a comment |
up vote
9
down vote
up vote
9
down vote
Small and easy!
Every piece of data stored in Google is actually split into multiple chunks. Each chunk is encrypted using a different key!
That's a lot of keys? How are they managed? Well, there are Key Management Servers (KMS) that take all those keys and encrypt them to ensure they are safe. Of course, the keys used to encrypt these keys also need to be encrypted. This goes until you get to the Root KMS key. This key exists on only a few machines in the datacenter... and if you can take all of these out (keep in mind, resiliency is built in by design) then nobody can decrypt any keys underneath it! All the data is still there, but meaningless and lost forever. This is similar to @nzaman's thinking, but already done, only requires impacting a few machines rather than every machine.
So it's not the size of the bomb, but the location(s) that makes all the difference.
https://cloud.google.com/security/encryption-at-rest/default-encryption/
Or is it?
Google isn't silly enough to trust all its keys to a single data center. There is always a risk that some massive power outage etc. would compromise the keys (stored in memory only) and losing that data would be disastrous. So there are two fail safes:
The Root KMS Master Key Distributor, essentially a P2P backup with other datacenters:
Root KMS in turn has its own root key, called the root KMS master key, which is also AES256 and is stored in a peer-to-peer infrastructure, the root KMS master key distributor, which replicates these keys globally. The root KMS master key distributor only holds the keys in RAM on the same dedicated machines as Root KMS
And the Safes:
To address the scenario where all instances of the root KMS master key distributor restart simultaneously, the root KMS master key is also backed up on secure hardware devices stored in physical safes in highly secured areas in two physically separated, global Google locations. This backup would be needed only if all distributor instances were to go down at once; for example, in a global restart. Fewer than 20 Google employees are able to access these safes.
Now whether or not these backup strategies exist in your world, or can be avoided through other means (e.g. more than one 'bomb') is entirely up to your world-building.
Small and easy!
Every piece of data stored in Google is actually split into multiple chunks. Each chunk is encrypted using a different key!
That's a lot of keys? How are they managed? Well, there are Key Management Servers (KMS) that take all those keys and encrypt them to ensure they are safe. Of course, the keys used to encrypt these keys also need to be encrypted. This goes until you get to the Root KMS key. This key exists on only a few machines in the datacenter... and if you can take all of these out (keep in mind, resiliency is built in by design) then nobody can decrypt any keys underneath it! All the data is still there, but meaningless and lost forever. This is similar to @nzaman's thinking, but already done, only requires impacting a few machines rather than every machine.
So it's not the size of the bomb, but the location(s) that makes all the difference.
https://cloud.google.com/security/encryption-at-rest/default-encryption/
Or is it?
Google isn't silly enough to trust all its keys to a single data center. There is always a risk that some massive power outage etc. would compromise the keys (stored in memory only) and losing that data would be disastrous. So there are two fail safes:
The Root KMS Master Key Distributor, essentially a P2P backup with other datacenters:
Root KMS in turn has its own root key, called the root KMS master key, which is also AES256 and is stored in a peer-to-peer infrastructure, the root KMS master key distributor, which replicates these keys globally. The root KMS master key distributor only holds the keys in RAM on the same dedicated machines as Root KMS
And the Safes:
To address the scenario where all instances of the root KMS master key distributor restart simultaneously, the root KMS master key is also backed up on secure hardware devices stored in physical safes in highly secured areas in two physically separated, global Google locations. This backup would be needed only if all distributor instances were to go down at once; for example, in a global restart. Fewer than 20 Google employees are able to access these safes.
Now whether or not these backup strategies exist in your world, or can be avoided through other means (e.g. more than one 'bomb') is entirely up to your world-building.
edited yesterday
answered Nov 27 at 20:09
NPSF3000
2,539813
2,539813
1
Huge portions of the Google DB have no reason to be encrypted. It is not a trade secret that the search crawler scanned diy.stackexchange.com/tour and stored a cache of it. Do they really encrypt all of that?
– Harper
Nov 27 at 20:12
This is wonderfully brilliant, and again would not work in my case. But it's also a horribly interesting fact, notwithstanding usability. Thanks for sharing it, I find the idea to be awesome. :)
– John S.
Nov 27 at 20:37
1
@Harper I presume yes. To give you an idea, that entire process that is described happens every single time you open an email, or every single time a google doc is autosaved. Google takes security very seriously and builds it into the foundation of the tools they use (e.g. at the data layer itself). Their database tool simply wouldn't have an option to not encrypt the data... it's not something that can be turned off.
– NPSF3000
Nov 27 at 21:18
1
@JohnS. My pleasure, hope your world comes together nicely.
– NPSF3000
Nov 27 at 21:19
@forest formatting issue, the 4 was a footnote reference. Fixed.
– NPSF3000
Nov 28 at 13:39
add a comment |
1
Huge portions of the Google DB have no reason to be encrypted. It is not a trade secret that the search crawler scanned diy.stackexchange.com/tour and stored a cache of it. Do they really encrypt all of that?
– Harper
Nov 27 at 20:12
This is wonderfully brilliant, and again would not work in my case. But it's also a horribly interesting fact, notwithstanding usability. Thanks for sharing it, I find the idea to be awesome. :)
– John S.
Nov 27 at 20:37
1
@Harper I presume yes. To give you an idea, that entire process that is described happens every single time you open an email, or every single time a google doc is autosaved. Google takes security very seriously and builds it into the foundation of the tools they use (e.g. at the data layer itself). Their database tool simply wouldn't have an option to not encrypt the data... it's not something that can be turned off.
– NPSF3000
Nov 27 at 21:18
1
@JohnS. My pleasure, hope your world comes together nicely.
– NPSF3000
Nov 27 at 21:19
@forest formatting issue, the 4 was a footnote reference. Fixed.
– NPSF3000
Nov 28 at 13:39
1
1
Huge portions of the Google DB have no reason to be encrypted. It is not a trade secret that the search crawler scanned diy.stackexchange.com/tour and stored a cache of it. Do they really encrypt all of that?
– Harper
Nov 27 at 20:12
Huge portions of the Google DB have no reason to be encrypted. It is not a trade secret that the search crawler scanned diy.stackexchange.com/tour and stored a cache of it. Do they really encrypt all of that?
– Harper
Nov 27 at 20:12
This is wonderfully brilliant, and again would not work in my case. But it's also a horribly interesting fact, notwithstanding usability. Thanks for sharing it, I find the idea to be awesome. :)
– John S.
Nov 27 at 20:37
This is wonderfully brilliant, and again would not work in my case. But it's also a horribly interesting fact, notwithstanding usability. Thanks for sharing it, I find the idea to be awesome. :)
– John S.
Nov 27 at 20:37
1
1
@Harper I presume yes. To give you an idea, that entire process that is described happens every single time you open an email, or every single time a google doc is autosaved. Google takes security very seriously and builds it into the foundation of the tools they use (e.g. at the data layer itself). Their database tool simply wouldn't have an option to not encrypt the data... it's not something that can be turned off.
– NPSF3000
Nov 27 at 21:18
@Harper I presume yes. To give you an idea, that entire process that is described happens every single time you open an email, or every single time a google doc is autosaved. Google takes security very seriously and builds it into the foundation of the tools they use (e.g. at the data layer itself). Their database tool simply wouldn't have an option to not encrypt the data... it's not something that can be turned off.
– NPSF3000
Nov 27 at 21:18
1
1
@JohnS. My pleasure, hope your world comes together nicely.
– NPSF3000
Nov 27 at 21:19
@JohnS. My pleasure, hope your world comes together nicely.
– NPSF3000
Nov 27 at 21:19
@forest formatting issue, the 4 was a footnote reference. Fixed.
– NPSF3000
Nov 28 at 13:39
@forest formatting issue, the 4 was a footnote reference. Fixed.
– NPSF3000
Nov 28 at 13:39
add a comment |
up vote
5
down vote
As others discuss, EMP will damage the machines that access the data, but not the data. You mention that your forces are owners or insiders, who can alter the design to suit, but need to conceal it from line staff who work there. I cannot see a non-detectable way to wipe the software without damaging your hardware. If you use internal malware, and even one backup survives, you are exposed. But to an evil genius, hardware is cheap. Let insurance buy you new hardware and that opens you up to many options. For instnace
Plain old fire
Burn the place to the ground. Simple as that. Build the place out of materials that'll squeak by the fire codes, but then store things in there that will subtly add to and sustain the conflagration. By "subtle" I mean that what fuels office building fires is the office trim and file cabinets full of paper. The trim can be made endothermic, the paper cannot. What's ironic about 9/11 is the jet fuel flashed off quickly, the paper sustained the fire.
Likewise, start the fire with liquid or gaseous fuel and let the paper finish the job. Of course you'd need to either damage the sprinkler system or subvert it to your purposes. Also strive to use more burnable materials where excusable, such as you will want servers with plastic cases, and SSD rather than HDD.
Lastly you'll want what steel mills and refineries actually do need: fire-truck-proof gates. Those industries don't want the F.D. yokels charging in and throwing a water hose on a hot metal bottle or sodium fire. In your case you are worried about terror attacks, or some other thing. And make sure to have onsite security doors which get F.D. Approval, but then frustrate their entry. Just build your building to make it hard to fight fires in, so they switch to 'let it burn out' and containment.
Locating in an unfinished nuclear reactor would be a fun way to do it.
Love the imagination, doesn't work in the context of my story, but love it nonetheless. :)
– John S.
Nov 27 at 18:53
2
Or "upgrade" the sprinkler systems to a new fire retardant that needs to be stored in a massive tank in the server farm. Then accidentally fill it full of some highly flammable fuels, instead of actual fire retardants :)
– X-27
Nov 27 at 23:44
2
@X-27 sure. Or I was just thinking, you have a diesel fire pump, the fire sprinkler lines are red because of the Fire Code, the diesel fuel lines are red because of the Mechanical Code or somesuch, tragic plumbing error.
– Harper
Nov 27 at 23:57
1
And remember, you can't put too much water in a nuclear reactor.
– manassehkatz
Nov 28 at 2:47
1
Fire is not actually as effective as you'd expect, you need to get up to some serious temperatures (probably 800-1000K to be sure). Given the OP's requirement for speed you're going to need to get the drive platters up to those temps quickly, Thermite works but deploying it might be tricky
– motosubatsu
Nov 28 at 9:36
|
show 2 more comments
up vote
5
down vote
As others discuss, EMP will damage the machines that access the data, but not the data. You mention that your forces are owners or insiders, who can alter the design to suit, but need to conceal it from line staff who work there. I cannot see a non-detectable way to wipe the software without damaging your hardware. If you use internal malware, and even one backup survives, you are exposed. But to an evil genius, hardware is cheap. Let insurance buy you new hardware and that opens you up to many options. For instnace
Plain old fire
Burn the place to the ground. Simple as that. Build the place out of materials that'll squeak by the fire codes, but then store things in there that will subtly add to and sustain the conflagration. By "subtle" I mean that what fuels office building fires is the office trim and file cabinets full of paper. The trim can be made endothermic, the paper cannot. What's ironic about 9/11 is the jet fuel flashed off quickly, the paper sustained the fire.
Likewise, start the fire with liquid or gaseous fuel and let the paper finish the job. Of course you'd need to either damage the sprinkler system or subvert it to your purposes. Also strive to use more burnable materials where excusable, such as you will want servers with plastic cases, and SSD rather than HDD.
Lastly you'll want what steel mills and refineries actually do need: fire-truck-proof gates. Those industries don't want the F.D. yokels charging in and throwing a water hose on a hot metal bottle or sodium fire. In your case you are worried about terror attacks, or some other thing. And make sure to have onsite security doors which get F.D. Approval, but then frustrate their entry. Just build your building to make it hard to fight fires in, so they switch to 'let it burn out' and containment.
Locating in an unfinished nuclear reactor would be a fun way to do it.
Love the imagination, doesn't work in the context of my story, but love it nonetheless. :)
– John S.
Nov 27 at 18:53
2
Or "upgrade" the sprinkler systems to a new fire retardant that needs to be stored in a massive tank in the server farm. Then accidentally fill it full of some highly flammable fuels, instead of actual fire retardants :)
– X-27
Nov 27 at 23:44
2
@X-27 sure. Or I was just thinking, you have a diesel fire pump, the fire sprinkler lines are red because of the Fire Code, the diesel fuel lines are red because of the Mechanical Code or somesuch, tragic plumbing error.
– Harper
Nov 27 at 23:57
1
And remember, you can't put too much water in a nuclear reactor.
– manassehkatz
Nov 28 at 2:47
1
Fire is not actually as effective as you'd expect, you need to get up to some serious temperatures (probably 800-1000K to be sure). Given the OP's requirement for speed you're going to need to get the drive platters up to those temps quickly, Thermite works but deploying it might be tricky
– motosubatsu
Nov 28 at 9:36
|
show 2 more comments
up vote
5
down vote
up vote
5
down vote
As others discuss, EMP will damage the machines that access the data, but not the data. You mention that your forces are owners or insiders, who can alter the design to suit, but need to conceal it from line staff who work there. I cannot see a non-detectable way to wipe the software without damaging your hardware. If you use internal malware, and even one backup survives, you are exposed. But to an evil genius, hardware is cheap. Let insurance buy you new hardware and that opens you up to many options. For instnace
Plain old fire
Burn the place to the ground. Simple as that. Build the place out of materials that'll squeak by the fire codes, but then store things in there that will subtly add to and sustain the conflagration. By "subtle" I mean that what fuels office building fires is the office trim and file cabinets full of paper. The trim can be made endothermic, the paper cannot. What's ironic about 9/11 is the jet fuel flashed off quickly, the paper sustained the fire.
Likewise, start the fire with liquid or gaseous fuel and let the paper finish the job. Of course you'd need to either damage the sprinkler system or subvert it to your purposes. Also strive to use more burnable materials where excusable, such as you will want servers with plastic cases, and SSD rather than HDD.
Lastly you'll want what steel mills and refineries actually do need: fire-truck-proof gates. Those industries don't want the F.D. yokels charging in and throwing a water hose on a hot metal bottle or sodium fire. In your case you are worried about terror attacks, or some other thing. And make sure to have onsite security doors which get F.D. Approval, but then frustrate their entry. Just build your building to make it hard to fight fires in, so they switch to 'let it burn out' and containment.
Locating in an unfinished nuclear reactor would be a fun way to do it.
As others discuss, EMP will damage the machines that access the data, but not the data. You mention that your forces are owners or insiders, who can alter the design to suit, but need to conceal it from line staff who work there. I cannot see a non-detectable way to wipe the software without damaging your hardware. If you use internal malware, and even one backup survives, you are exposed. But to an evil genius, hardware is cheap. Let insurance buy you new hardware and that opens you up to many options. For instnace
Plain old fire
Burn the place to the ground. Simple as that. Build the place out of materials that'll squeak by the fire codes, but then store things in there that will subtly add to and sustain the conflagration. By "subtle" I mean that what fuels office building fires is the office trim and file cabinets full of paper. The trim can be made endothermic, the paper cannot. What's ironic about 9/11 is the jet fuel flashed off quickly, the paper sustained the fire.
Likewise, start the fire with liquid or gaseous fuel and let the paper finish the job. Of course you'd need to either damage the sprinkler system or subvert it to your purposes. Also strive to use more burnable materials where excusable, such as you will want servers with plastic cases, and SSD rather than HDD.
Lastly you'll want what steel mills and refineries actually do need: fire-truck-proof gates. Those industries don't want the F.D. yokels charging in and throwing a water hose on a hot metal bottle or sodium fire. In your case you are worried about terror attacks, or some other thing. And make sure to have onsite security doors which get F.D. Approval, but then frustrate their entry. Just build your building to make it hard to fight fires in, so they switch to 'let it burn out' and containment.
Locating in an unfinished nuclear reactor would be a fun way to do it.
edited Nov 27 at 19:15
answered Nov 27 at 18:39
Harper
5,150621
5,150621
Love the imagination, doesn't work in the context of my story, but love it nonetheless. :)
– John S.
Nov 27 at 18:53
2
Or "upgrade" the sprinkler systems to a new fire retardant that needs to be stored in a massive tank in the server farm. Then accidentally fill it full of some highly flammable fuels, instead of actual fire retardants :)
– X-27
Nov 27 at 23:44
2
@X-27 sure. Or I was just thinking, you have a diesel fire pump, the fire sprinkler lines are red because of the Fire Code, the diesel fuel lines are red because of the Mechanical Code or somesuch, tragic plumbing error.
– Harper
Nov 27 at 23:57
1
And remember, you can't put too much water in a nuclear reactor.
– manassehkatz
Nov 28 at 2:47
1
Fire is not actually as effective as you'd expect, you need to get up to some serious temperatures (probably 800-1000K to be sure). Given the OP's requirement for speed you're going to need to get the drive platters up to those temps quickly, Thermite works but deploying it might be tricky
– motosubatsu
Nov 28 at 9:36
|
show 2 more comments
Love the imagination, doesn't work in the context of my story, but love it nonetheless. :)
– John S.
Nov 27 at 18:53
2
Or "upgrade" the sprinkler systems to a new fire retardant that needs to be stored in a massive tank in the server farm. Then accidentally fill it full of some highly flammable fuels, instead of actual fire retardants :)
– X-27
Nov 27 at 23:44
2
@X-27 sure. Or I was just thinking, you have a diesel fire pump, the fire sprinkler lines are red because of the Fire Code, the diesel fuel lines are red because of the Mechanical Code or somesuch, tragic plumbing error.
– Harper
Nov 27 at 23:57
1
And remember, you can't put too much water in a nuclear reactor.
– manassehkatz
Nov 28 at 2:47
1
Fire is not actually as effective as you'd expect, you need to get up to some serious temperatures (probably 800-1000K to be sure). Given the OP's requirement for speed you're going to need to get the drive platters up to those temps quickly, Thermite works but deploying it might be tricky
– motosubatsu
Nov 28 at 9:36
Love the imagination, doesn't work in the context of my story, but love it nonetheless. :)
– John S.
Nov 27 at 18:53
Love the imagination, doesn't work in the context of my story, but love it nonetheless. :)
– John S.
Nov 27 at 18:53
2
2
Or "upgrade" the sprinkler systems to a new fire retardant that needs to be stored in a massive tank in the server farm. Then accidentally fill it full of some highly flammable fuels, instead of actual fire retardants :)
– X-27
Nov 27 at 23:44
Or "upgrade" the sprinkler systems to a new fire retardant that needs to be stored in a massive tank in the server farm. Then accidentally fill it full of some highly flammable fuels, instead of actual fire retardants :)
– X-27
Nov 27 at 23:44
2
2
@X-27 sure. Or I was just thinking, you have a diesel fire pump, the fire sprinkler lines are red because of the Fire Code, the diesel fuel lines are red because of the Mechanical Code or somesuch, tragic plumbing error.
– Harper
Nov 27 at 23:57
@X-27 sure. Or I was just thinking, you have a diesel fire pump, the fire sprinkler lines are red because of the Fire Code, the diesel fuel lines are red because of the Mechanical Code or somesuch, tragic plumbing error.
– Harper
Nov 27 at 23:57
1
1
And remember, you can't put too much water in a nuclear reactor.
– manassehkatz
Nov 28 at 2:47
And remember, you can't put too much water in a nuclear reactor.
– manassehkatz
Nov 28 at 2:47
1
1
Fire is not actually as effective as you'd expect, you need to get up to some serious temperatures (probably 800-1000K to be sure). Given the OP's requirement for speed you're going to need to get the drive platters up to those temps quickly, Thermite works but deploying it might be tricky
– motosubatsu
Nov 28 at 9:36
Fire is not actually as effective as you'd expect, you need to get up to some serious temperatures (probably 800-1000K to be sure). Given the OP's requirement for speed you're going to need to get the drive platters up to those temps quickly, Thermite works but deploying it might be tricky
– motosubatsu
Nov 28 at 9:36
|
show 2 more comments
up vote
5
down vote
Sound Waves!
Years ago, I was working on some laptop theft prevention software, which in addition to a hardware alarm would activate a laptop's speaker. I had an odd situation on a particular Asus Aspire One laptop where the software would work great while testing, but every time a demo was done, it would BSOD. Naturally, this didn't make my client very happy. I worked on the problem for months trying to figure out what was going on. The problem never occurred on my laptop, only his demo laptop. I ended up buying extra laptops to test. At one point we went to go buy a second of that type of laptop. While looking up the model number, I found an article stating a particular fatal flaw. The speaker was mounted directly on top of the hard drive. At a particular frequency range, the hard drive would basically wreck the data coming out of it, which caused Windows to crash because swapfile was in-use because this laptop also had very little RAM. That particular frequency range happened to be almost exactly what I had chosen for my alarm sound effect. When I would test, the volume was way way down. But, during demos, we would crank it up and almost guarantee a blue screen.
This problem made me start to wonder about other places this could be a problem. Around the same time, some guy posted a video of himself screaming at a hard drive array, causing read latency to increase: https://www.youtube.com/watch?v=tDacjrSCeq4
Since then, I've thought that a particularly crafty malicious hacker could build a device with a bunch of ultrasonic transducers, and hidden somehow in a rack in a cage in a datacenter. With ultrasonic, while you can't hear it, you can create an interference pattern by using two lower frequencies that is in the range of what you need, while retaining the property of having an extremely directional beam. Your device could effectively shoot sonic lasers at particular devices in the datacenter, causing glitches-to-complete-failures in magnetic hard drives, all while not being heard by humans unless they were in the direct path at the time.
Most of the drives for bulk storage are magnetic, with read/write heads barely floating above the drive platters spinning crazy fast underneath. Everything has to be perfectly in balance.
SSDs don't have this trouble, so this method won't apply to them.
New contributor
1
This won't destroy the data, just make read operations fail while the sonic "laser" is on. Anyway, +1 for creativity.
– Guntram Blohm
Nov 28 at 6:11
@GuntramBlohm Ah, to clarify I figured since we're talking EMP levels here to begin with, you could get some very powerful transducers to totally wreck things. However, reconsidering this today, I now realize you would basically destroy the entire facility if you could somehow push that much energy through such a device. :-)
– Brad
Nov 28 at 14:08
add a comment |
up vote
5
down vote
Sound Waves!
Years ago, I was working on some laptop theft prevention software, which in addition to a hardware alarm would activate a laptop's speaker. I had an odd situation on a particular Asus Aspire One laptop where the software would work great while testing, but every time a demo was done, it would BSOD. Naturally, this didn't make my client very happy. I worked on the problem for months trying to figure out what was going on. The problem never occurred on my laptop, only his demo laptop. I ended up buying extra laptops to test. At one point we went to go buy a second of that type of laptop. While looking up the model number, I found an article stating a particular fatal flaw. The speaker was mounted directly on top of the hard drive. At a particular frequency range, the hard drive would basically wreck the data coming out of it, which caused Windows to crash because swapfile was in-use because this laptop also had very little RAM. That particular frequency range happened to be almost exactly what I had chosen for my alarm sound effect. When I would test, the volume was way way down. But, during demos, we would crank it up and almost guarantee a blue screen.
This problem made me start to wonder about other places this could be a problem. Around the same time, some guy posted a video of himself screaming at a hard drive array, causing read latency to increase: https://www.youtube.com/watch?v=tDacjrSCeq4
Since then, I've thought that a particularly crafty malicious hacker could build a device with a bunch of ultrasonic transducers, and hidden somehow in a rack in a cage in a datacenter. With ultrasonic, while you can't hear it, you can create an interference pattern by using two lower frequencies that is in the range of what you need, while retaining the property of having an extremely directional beam. Your device could effectively shoot sonic lasers at particular devices in the datacenter, causing glitches-to-complete-failures in magnetic hard drives, all while not being heard by humans unless they were in the direct path at the time.
Most of the drives for bulk storage are magnetic, with read/write heads barely floating above the drive platters spinning crazy fast underneath. Everything has to be perfectly in balance.
SSDs don't have this trouble, so this method won't apply to them.
New contributor
1
This won't destroy the data, just make read operations fail while the sonic "laser" is on. Anyway, +1 for creativity.
– Guntram Blohm
Nov 28 at 6:11
@GuntramBlohm Ah, to clarify I figured since we're talking EMP levels here to begin with, you could get some very powerful transducers to totally wreck things. However, reconsidering this today, I now realize you would basically destroy the entire facility if you could somehow push that much energy through such a device. :-)
– Brad
Nov 28 at 14:08
add a comment |
up vote
5
down vote
up vote
5
down vote
Sound Waves!
Years ago, I was working on some laptop theft prevention software, which in addition to a hardware alarm would activate a laptop's speaker. I had an odd situation on a particular Asus Aspire One laptop where the software would work great while testing, but every time a demo was done, it would BSOD. Naturally, this didn't make my client very happy. I worked on the problem for months trying to figure out what was going on. The problem never occurred on my laptop, only his demo laptop. I ended up buying extra laptops to test. At one point we went to go buy a second of that type of laptop. While looking up the model number, I found an article stating a particular fatal flaw. The speaker was mounted directly on top of the hard drive. At a particular frequency range, the hard drive would basically wreck the data coming out of it, which caused Windows to crash because swapfile was in-use because this laptop also had very little RAM. That particular frequency range happened to be almost exactly what I had chosen for my alarm sound effect. When I would test, the volume was way way down. But, during demos, we would crank it up and almost guarantee a blue screen.
This problem made me start to wonder about other places this could be a problem. Around the same time, some guy posted a video of himself screaming at a hard drive array, causing read latency to increase: https://www.youtube.com/watch?v=tDacjrSCeq4
Since then, I've thought that a particularly crafty malicious hacker could build a device with a bunch of ultrasonic transducers, and hidden somehow in a rack in a cage in a datacenter. With ultrasonic, while you can't hear it, you can create an interference pattern by using two lower frequencies that is in the range of what you need, while retaining the property of having an extremely directional beam. Your device could effectively shoot sonic lasers at particular devices in the datacenter, causing glitches-to-complete-failures in magnetic hard drives, all while not being heard by humans unless they were in the direct path at the time.
Most of the drives for bulk storage are magnetic, with read/write heads barely floating above the drive platters spinning crazy fast underneath. Everything has to be perfectly in balance.
SSDs don't have this trouble, so this method won't apply to them.
New contributor
Sound Waves!
Years ago, I was working on some laptop theft prevention software, which in addition to a hardware alarm would activate a laptop's speaker. I had an odd situation on a particular Asus Aspire One laptop where the software would work great while testing, but every time a demo was done, it would BSOD. Naturally, this didn't make my client very happy. I worked on the problem for months trying to figure out what was going on. The problem never occurred on my laptop, only his demo laptop. I ended up buying extra laptops to test. At one point we went to go buy a second of that type of laptop. While looking up the model number, I found an article stating a particular fatal flaw. The speaker was mounted directly on top of the hard drive. At a particular frequency range, the hard drive would basically wreck the data coming out of it, which caused Windows to crash because swapfile was in-use because this laptop also had very little RAM. That particular frequency range happened to be almost exactly what I had chosen for my alarm sound effect. When I would test, the volume was way way down. But, during demos, we would crank it up and almost guarantee a blue screen.
This problem made me start to wonder about other places this could be a problem. Around the same time, some guy posted a video of himself screaming at a hard drive array, causing read latency to increase: https://www.youtube.com/watch?v=tDacjrSCeq4
Since then, I've thought that a particularly crafty malicious hacker could build a device with a bunch of ultrasonic transducers, and hidden somehow in a rack in a cage in a datacenter. With ultrasonic, while you can't hear it, you can create an interference pattern by using two lower frequencies that is in the range of what you need, while retaining the property of having an extremely directional beam. Your device could effectively shoot sonic lasers at particular devices in the datacenter, causing glitches-to-complete-failures in magnetic hard drives, all while not being heard by humans unless they were in the direct path at the time.
Most of the drives for bulk storage are magnetic, with read/write heads barely floating above the drive platters spinning crazy fast underneath. Everything has to be perfectly in balance.
SSDs don't have this trouble, so this method won't apply to them.
New contributor
New contributor
answered Nov 28 at 5:07
Brad
1513
1513
New contributor
New contributor
1
This won't destroy the data, just make read operations fail while the sonic "laser" is on. Anyway, +1 for creativity.
– Guntram Blohm
Nov 28 at 6:11
@GuntramBlohm Ah, to clarify I figured since we're talking EMP levels here to begin with, you could get some very powerful transducers to totally wreck things. However, reconsidering this today, I now realize you would basically destroy the entire facility if you could somehow push that much energy through such a device. :-)
– Brad
Nov 28 at 14:08
add a comment |
1
This won't destroy the data, just make read operations fail while the sonic "laser" is on. Anyway, +1 for creativity.
– Guntram Blohm
Nov 28 at 6:11
@GuntramBlohm Ah, to clarify I figured since we're talking EMP levels here to begin with, you could get some very powerful transducers to totally wreck things. However, reconsidering this today, I now realize you would basically destroy the entire facility if you could somehow push that much energy through such a device. :-)
– Brad
Nov 28 at 14:08
1
1
This won't destroy the data, just make read operations fail while the sonic "laser" is on. Anyway, +1 for creativity.
– Guntram Blohm
Nov 28 at 6:11
This won't destroy the data, just make read operations fail while the sonic "laser" is on. Anyway, +1 for creativity.
– Guntram Blohm
Nov 28 at 6:11
@GuntramBlohm Ah, to clarify I figured since we're talking EMP levels here to begin with, you could get some very powerful transducers to totally wreck things. However, reconsidering this today, I now realize you would basically destroy the entire facility if you could somehow push that much energy through such a device. :-)
– Brad
Nov 28 at 14:08
@GuntramBlohm Ah, to clarify I figured since we're talking EMP levels here to begin with, you could get some very powerful transducers to totally wreck things. However, reconsidering this today, I now realize you would basically destroy the entire facility if you could somehow push that much energy through such a device. :-)
– Brad
Nov 28 at 14:08
add a comment |
up vote
4
down vote
It isn't only a question of how big, but a question of where. EMP on the data bus is a different beast from EMP in the power supply, which is a different beast from a simple EMP generator within the room but not connected to anything.
Case 1: EMP in the data buses
The most difficult to create, but also the most devastating. You are supplying a high voltage in the cables through which the data passes. Assuming no intermediate devices burn out, your EMP will make it all the way to the storage drives and work their damage there. No guarantees that nothing can be recovered by forensic examination of the disks, but the disks themselves will be unusable.
Getting a high voltage pulse into those cables is near impossible, unless you have physical access to them, as the cables are shielded against EMP for precisely this reason. If you do have physical access, introducing malware or something similar is a better way to do things. If you're a three-letter agency, for instance, you'll find it more rewarding to spy on people's data, rather than deleting it.
Case 2: EMP in the power supply
By far easier than case 1 and far more likely to happen, given exposed transmission lines. Except that any data centre will have decoupling and power conditioning systems before the power supply gets anywhere near the data, to ensure no unwanted spikes or dips get through. Unless you're actually inside the data centre,or better yet, inside the actual server room, in case they have a final redundant decoupling system, you're not likely to do much damage.
Assuming everything goes your way, and you do successfully set off an EMP after bypassing all the protections, you'll destroy the servers, but probably not most of the data. They will need forensics to recover it, but it can be recovered. The electronics will be slagged, however, so the servers will probably be unusable.
Case 3: EMP inside the server room
Comparatively, the easiest way to cause some damage, but overall likelihood of causing less damage than a successful attempt at Case 1 or 2. Your EMP will weaken with the square of distance, so a million volts or so will be needed to get the whole room, given that the server enclosures will act as Faraday cages and protect their insides. With less voltage, you'll destroy everything nearby, with damage tapering off as you go further from ground zero. This depends on the geometry of the room and the kind of earthing in place. A rectangular room will take less damage than a square room; an L-shape will take less damage, unless the EMP goes off in the crook of the L.
I really like your answer. What you said about the Faraday cage is very important, because almost every mass storage device is encased in a metal shell. The actual data most likely will not be wiped out by a EMP. The electronics sitting outside the Faraday cage will be destroyed, however, unless those mass storage devices are sitting inside a metal RAID array enclosure. Then the only exposed wiring would be the power cord and data cable.
– hyperion4
Nov 27 at 15:56
So assuming you have full access to the entire server facility, unlimited resources, access and time, putting them into the data bus would work. Would this also destroy all the servers themselves, as they pass data through the bus, or only the storage devices? What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged. Either way, helpful answer, if not exactly what I need. :)
– John S.
Nov 27 at 16:11
1
@JohnSiskar: It depends on the size of the spike. A series of low voltage spikes could corrupt the data and leave the hardware unharmed. A large spike would fry the electronics and leave the data unaffected. The problem with random effects is that you can't guarantee the outcome
– nzaman
Nov 27 at 16:15
1
@JohnS The data bus has some built in error correction. Data centers use fibre channel or iSCSI though, which means OPTICAL cables, which are immune to electromagnetic interference,so the only vulnerable points would be the metal connectors holding the optical cables to the drive array and CPU motherboards. However, I doubt most computer enclosures act as ideal Faraday cages so the CPUs would fry before the hard drives lose data.
– hyperion4
Nov 28 at 1:29
add a comment |
up vote
4
down vote
It isn't only a question of how big, but a question of where. EMP on the data bus is a different beast from EMP in the power supply, which is a different beast from a simple EMP generator within the room but not connected to anything.
Case 1: EMP in the data buses
The most difficult to create, but also the most devastating. You are supplying a high voltage in the cables through which the data passes. Assuming no intermediate devices burn out, your EMP will make it all the way to the storage drives and work their damage there. No guarantees that nothing can be recovered by forensic examination of the disks, but the disks themselves will be unusable.
Getting a high voltage pulse into those cables is near impossible, unless you have physical access to them, as the cables are shielded against EMP for precisely this reason. If you do have physical access, introducing malware or something similar is a better way to do things. If you're a three-letter agency, for instance, you'll find it more rewarding to spy on people's data, rather than deleting it.
Case 2: EMP in the power supply
By far easier than case 1 and far more likely to happen, given exposed transmission lines. Except that any data centre will have decoupling and power conditioning systems before the power supply gets anywhere near the data, to ensure no unwanted spikes or dips get through. Unless you're actually inside the data centre,or better yet, inside the actual server room, in case they have a final redundant decoupling system, you're not likely to do much damage.
Assuming everything goes your way, and you do successfully set off an EMP after bypassing all the protections, you'll destroy the servers, but probably not most of the data. They will need forensics to recover it, but it can be recovered. The electronics will be slagged, however, so the servers will probably be unusable.
Case 3: EMP inside the server room
Comparatively, the easiest way to cause some damage, but overall likelihood of causing less damage than a successful attempt at Case 1 or 2. Your EMP will weaken with the square of distance, so a million volts or so will be needed to get the whole room, given that the server enclosures will act as Faraday cages and protect their insides. With less voltage, you'll destroy everything nearby, with damage tapering off as you go further from ground zero. This depends on the geometry of the room and the kind of earthing in place. A rectangular room will take less damage than a square room; an L-shape will take less damage, unless the EMP goes off in the crook of the L.
I really like your answer. What you said about the Faraday cage is very important, because almost every mass storage device is encased in a metal shell. The actual data most likely will not be wiped out by a EMP. The electronics sitting outside the Faraday cage will be destroyed, however, unless those mass storage devices are sitting inside a metal RAID array enclosure. Then the only exposed wiring would be the power cord and data cable.
– hyperion4
Nov 27 at 15:56
So assuming you have full access to the entire server facility, unlimited resources, access and time, putting them into the data bus would work. Would this also destroy all the servers themselves, as they pass data through the bus, or only the storage devices? What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged. Either way, helpful answer, if not exactly what I need. :)
– John S.
Nov 27 at 16:11
1
@JohnSiskar: It depends on the size of the spike. A series of low voltage spikes could corrupt the data and leave the hardware unharmed. A large spike would fry the electronics and leave the data unaffected. The problem with random effects is that you can't guarantee the outcome
– nzaman
Nov 27 at 16:15
1
@JohnS The data bus has some built in error correction. Data centers use fibre channel or iSCSI though, which means OPTICAL cables, which are immune to electromagnetic interference,so the only vulnerable points would be the metal connectors holding the optical cables to the drive array and CPU motherboards. However, I doubt most computer enclosures act as ideal Faraday cages so the CPUs would fry before the hard drives lose data.
– hyperion4
Nov 28 at 1:29
add a comment |
up vote
4
down vote
up vote
4
down vote
It isn't only a question of how big, but a question of where. EMP on the data bus is a different beast from EMP in the power supply, which is a different beast from a simple EMP generator within the room but not connected to anything.
Case 1: EMP in the data buses
The most difficult to create, but also the most devastating. You are supplying a high voltage in the cables through which the data passes. Assuming no intermediate devices burn out, your EMP will make it all the way to the storage drives and work their damage there. No guarantees that nothing can be recovered by forensic examination of the disks, but the disks themselves will be unusable.
Getting a high voltage pulse into those cables is near impossible, unless you have physical access to them, as the cables are shielded against EMP for precisely this reason. If you do have physical access, introducing malware or something similar is a better way to do things. If you're a three-letter agency, for instance, you'll find it more rewarding to spy on people's data, rather than deleting it.
Case 2: EMP in the power supply
By far easier than case 1 and far more likely to happen, given exposed transmission lines. Except that any data centre will have decoupling and power conditioning systems before the power supply gets anywhere near the data, to ensure no unwanted spikes or dips get through. Unless you're actually inside the data centre,or better yet, inside the actual server room, in case they have a final redundant decoupling system, you're not likely to do much damage.
Assuming everything goes your way, and you do successfully set off an EMP after bypassing all the protections, you'll destroy the servers, but probably not most of the data. They will need forensics to recover it, but it can be recovered. The electronics will be slagged, however, so the servers will probably be unusable.
Case 3: EMP inside the server room
Comparatively, the easiest way to cause some damage, but overall likelihood of causing less damage than a successful attempt at Case 1 or 2. Your EMP will weaken with the square of distance, so a million volts or so will be needed to get the whole room, given that the server enclosures will act as Faraday cages and protect their insides. With less voltage, you'll destroy everything nearby, with damage tapering off as you go further from ground zero. This depends on the geometry of the room and the kind of earthing in place. A rectangular room will take less damage than a square room; an L-shape will take less damage, unless the EMP goes off in the crook of the L.
It isn't only a question of how big, but a question of where. EMP on the data bus is a different beast from EMP in the power supply, which is a different beast from a simple EMP generator within the room but not connected to anything.
Case 1: EMP in the data buses
The most difficult to create, but also the most devastating. You are supplying a high voltage in the cables through which the data passes. Assuming no intermediate devices burn out, your EMP will make it all the way to the storage drives and work their damage there. No guarantees that nothing can be recovered by forensic examination of the disks, but the disks themselves will be unusable.
Getting a high voltage pulse into those cables is near impossible, unless you have physical access to them, as the cables are shielded against EMP for precisely this reason. If you do have physical access, introducing malware or something similar is a better way to do things. If you're a three-letter agency, for instance, you'll find it more rewarding to spy on people's data, rather than deleting it.
Case 2: EMP in the power supply
By far easier than case 1 and far more likely to happen, given exposed transmission lines. Except that any data centre will have decoupling and power conditioning systems before the power supply gets anywhere near the data, to ensure no unwanted spikes or dips get through. Unless you're actually inside the data centre,or better yet, inside the actual server room, in case they have a final redundant decoupling system, you're not likely to do much damage.
Assuming everything goes your way, and you do successfully set off an EMP after bypassing all the protections, you'll destroy the servers, but probably not most of the data. They will need forensics to recover it, but it can be recovered. The electronics will be slagged, however, so the servers will probably be unusable.
Case 3: EMP inside the server room
Comparatively, the easiest way to cause some damage, but overall likelihood of causing less damage than a successful attempt at Case 1 or 2. Your EMP will weaken with the square of distance, so a million volts or so will be needed to get the whole room, given that the server enclosures will act as Faraday cages and protect their insides. With less voltage, you'll destroy everything nearby, with damage tapering off as you go further from ground zero. This depends on the geometry of the room and the kind of earthing in place. A rectangular room will take less damage than a square room; an L-shape will take less damage, unless the EMP goes off in the crook of the L.
answered Nov 27 at 15:11
nzaman
8,81711443
8,81711443
I really like your answer. What you said about the Faraday cage is very important, because almost every mass storage device is encased in a metal shell. The actual data most likely will not be wiped out by a EMP. The electronics sitting outside the Faraday cage will be destroyed, however, unless those mass storage devices are sitting inside a metal RAID array enclosure. Then the only exposed wiring would be the power cord and data cable.
– hyperion4
Nov 27 at 15:56
So assuming you have full access to the entire server facility, unlimited resources, access and time, putting them into the data bus would work. Would this also destroy all the servers themselves, as they pass data through the bus, or only the storage devices? What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged. Either way, helpful answer, if not exactly what I need. :)
– John S.
Nov 27 at 16:11
1
@JohnSiskar: It depends on the size of the spike. A series of low voltage spikes could corrupt the data and leave the hardware unharmed. A large spike would fry the electronics and leave the data unaffected. The problem with random effects is that you can't guarantee the outcome
– nzaman
Nov 27 at 16:15
1
@JohnS The data bus has some built in error correction. Data centers use fibre channel or iSCSI though, which means OPTICAL cables, which are immune to electromagnetic interference,so the only vulnerable points would be the metal connectors holding the optical cables to the drive array and CPU motherboards. However, I doubt most computer enclosures act as ideal Faraday cages so the CPUs would fry before the hard drives lose data.
– hyperion4
Nov 28 at 1:29
add a comment |
I really like your answer. What you said about the Faraday cage is very important, because almost every mass storage device is encased in a metal shell. The actual data most likely will not be wiped out by a EMP. The electronics sitting outside the Faraday cage will be destroyed, however, unless those mass storage devices are sitting inside a metal RAID array enclosure. Then the only exposed wiring would be the power cord and data cable.
– hyperion4
Nov 27 at 15:56
So assuming you have full access to the entire server facility, unlimited resources, access and time, putting them into the data bus would work. Would this also destroy all the servers themselves, as they pass data through the bus, or only the storage devices? What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged. Either way, helpful answer, if not exactly what I need. :)
– John S.
Nov 27 at 16:11
1
@JohnSiskar: It depends on the size of the spike. A series of low voltage spikes could corrupt the data and leave the hardware unharmed. A large spike would fry the electronics and leave the data unaffected. The problem with random effects is that you can't guarantee the outcome
– nzaman
Nov 27 at 16:15
1
@JohnS The data bus has some built in error correction. Data centers use fibre channel or iSCSI though, which means OPTICAL cables, which are immune to electromagnetic interference,so the only vulnerable points would be the metal connectors holding the optical cables to the drive array and CPU motherboards. However, I doubt most computer enclosures act as ideal Faraday cages so the CPUs would fry before the hard drives lose data.
– hyperion4
Nov 28 at 1:29
I really like your answer. What you said about the Faraday cage is very important, because almost every mass storage device is encased in a metal shell. The actual data most likely will not be wiped out by a EMP. The electronics sitting outside the Faraday cage will be destroyed, however, unless those mass storage devices are sitting inside a metal RAID array enclosure. Then the only exposed wiring would be the power cord and data cable.
– hyperion4
Nov 27 at 15:56
I really like your answer. What you said about the Faraday cage is very important, because almost every mass storage device is encased in a metal shell. The actual data most likely will not be wiped out by a EMP. The electronics sitting outside the Faraday cage will be destroyed, however, unless those mass storage devices are sitting inside a metal RAID array enclosure. Then the only exposed wiring would be the power cord and data cable.
– hyperion4
Nov 27 at 15:56
So assuming you have full access to the entire server facility, unlimited resources, access and time, putting them into the data bus would work. Would this also destroy all the servers themselves, as they pass data through the bus, or only the storage devices? What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged. Either way, helpful answer, if not exactly what I need. :)
– John S.
Nov 27 at 16:11
So assuming you have full access to the entire server facility, unlimited resources, access and time, putting them into the data bus would work. Would this also destroy all the servers themselves, as they pass data through the bus, or only the storage devices? What I'm looking for is a hardware based solution to wiping out all the hard drives that's not likely to be detected by people working on the hardware. Software could, and would in the context of the story, be found and purged. Either way, helpful answer, if not exactly what I need. :)
– John S.
Nov 27 at 16:11
1
1
@JohnSiskar: It depends on the size of the spike. A series of low voltage spikes could corrupt the data and leave the hardware unharmed. A large spike would fry the electronics and leave the data unaffected. The problem with random effects is that you can't guarantee the outcome
– nzaman
Nov 27 at 16:15
@JohnSiskar: It depends on the size of the spike. A series of low voltage spikes could corrupt the data and leave the hardware unharmed. A large spike would fry the electronics and leave the data unaffected. The problem with random effects is that you can't guarantee the outcome
– nzaman
Nov 27 at 16:15
1
1
@JohnS The data bus has some built in error correction. Data centers use fibre channel or iSCSI though, which means OPTICAL cables, which are immune to electromagnetic interference,so the only vulnerable points would be the metal connectors holding the optical cables to the drive array and CPU motherboards. However, I doubt most computer enclosures act as ideal Faraday cages so the CPUs would fry before the hard drives lose data.
– hyperion4
Nov 28 at 1:29
@JohnS The data bus has some built in error correction. Data centers use fibre channel or iSCSI though, which means OPTICAL cables, which are immune to electromagnetic interference,so the only vulnerable points would be the metal connectors holding the optical cables to the drive array and CPU motherboards. However, I doubt most computer enclosures act as ideal Faraday cages so the CPUs would fry before the hard drives lose data.
– hyperion4
Nov 28 at 1:29
add a comment |
up vote
2
down vote
Use paper stickers with housekeeping information to keep track of your disk drives!
How would it help? Well, the stickers can have flat coils inside, just like those stickers that make detectors at shop exits beep at you. The coils can do the EMP and degaussing stuff, while also doubling as an antenna for a small control chip. That tiny low-power chip, and the coil, can be powered from a relatively small capacitor, which can be hidden under the sticker too. (Or inside the case, in case of SSDs, as those rarely have big enough cavities on the outside to hide the capacitor in.) The capacitor is absolutely essential in the case that the disk is completely disconnected for maintenance or other reasons when the kill-switch is triggered. It is recharged when the disk is online.
Sticking that coil right to the disk's circuit board should allow for small enough capacitor to kill whatever chips are on the other side with EMP, or to degauss the platters. For SSDs that extra capacitor can also be connected directly to the board instead, frying all the flash chips as soon as the signal comes. Maybe that small controller could also be connected directly to the motor and the heads of an HDD, making it literally scratch out all the data by slowly spinning the platters under unparked heads.
Add a powerful enough wireless transmitter to cover the whole complex, and a big red button (or a small gray one) for the trigger, and you are set! Keep in mind, though, that if someone tears off a sticker and notices a capacitor that's not connected to anything, they might suspect something and take a closer look at the sticker... With that caveat in mind, I think the idea is quite plausible. Someone might have to figure out exactly how big the capacitor has to actually be, but at least for frying flash in SSDs you most definitely can buy powerful enough yet really small caps.
My original idea follows:
Software could, and would in the context of the story, be found and purged.
What about embedded software? Modern computers are very damn smart. Every sizable component has a CPU, be it a network adapter or a microSD card.
Intel AMT allows you to connect to a server remotely and work on it like it's in front of you: a display, a keyboard, you can even "plug in" your hard disk into it over the network. And the best part is, all this works as soon as you press the power button (some of it even before that), and it is completely out-of-band. That last bit means that any software working on this server will never see any AMT traffic, and it will think that you've actually opened up the case and attached that HDD.
Despite having all that functionality, AMT works almost entirely on the motherboard itself, doesn't touch the main CPU or RAM, and is almost invisible to the "main" system. It's code is very obscure, extremely platform-specific and proprietary. Only some very smart hackers managed to get into it (and find a few glaring security holes...), under the normal circumstances no one will ever touch it in any way other than through the official client software from Intel.
Every HDD and SSD has an embedded controller, too. Wiping an SSD "from the inside" is as simple as "forgetting" where the index for all of its flash memory is, maybe wiping that relatively small index beforehand for good measure. And on HDD you can just slow down the platters enough for the heads to land on them and dig trenches all over the surface. (The heads are too weak to magnetically damage the data quickly enough, so physically damaging the surface is the only way.)
All the network hardware also has embedded processors, even the "really" embedded ones in case of bigger devices that are like normal computers themselves on the inside.
What I'm getting at is, most people don't even realize that their microSD card may well be more computationally powerful than a PC from late 90s! No one ever really looks inside those embedded chips. Oftentimes you cannot even read the firmware from them, only flash the updates. (And thus their security is severely lacking oftentimes, except the "Security through Obscurity" kind.)
If some kind of backdoor is installed on that level, I doubt that anyone will ever notice it. At least not until it's exploited and forensics start digging into the chips. No "normal" software will be able to detect that something's wrong, you'd have to take the device apart and dig in with a JTAG debugger to even have a chance.
Let's say that one of the routers in the datacenter receives a malformed packet. It looks like it's a normal packet that got (unnaturally severely) corrupted in transit. Normally, it would be silently dropped, and higher level protocol, like TCP, will request retransmission. Suddenly, the router broadcasts that same packet over all its connections, and then immediately "dies", maybe requiring a firmware recovery procedure to continue functioning. Every server that receives the packet suddenly crashes due to CPU voltage dropping below acceptable minimum, and its disks experience catastrophic firmware failure that destroys all the data in a matter of seconds. A few more seconds later, the "smart" power supply infrastructure, which also received the packet of death, cuts the power to the whole complex. And perimeter routers just receive and drop the packet as they should, not a single bit of suspicious data gets outside.
In just 10 seconds or so, the datacenter inexplicably goes from perfectly fine and healthy to totally blacked out and dead. All the networking infrastructure is lacking any firmware to even work. All the data is lost, either in unintelligible fragments randomly scattered across several flash chips in each SSD, or literally scattered all over the insides of HDDs.
No one has any clue as to what has happened. Even if someone figures out later that the firmware of almost everything in the complex had peculiar bugs that just so happened to act together in such devastating manner, it can still look like it all was an accident. Since there are no traces of the packet that caused the whole mess, the only way someone might figure out that it was malicious is by contacting HDD vendors and finding out that the firmware slightly differs from what should have been there, but even that would be practically impossible to say for sure, due to how much things change internally during product life cycle.
And in that last bit lies the catch. That 'small team' of yours will have to reverse engineer the firmware of every HDD, SSD, motherboard, network card and router in the datacenter, plus the smart power supply system. There likely will only be just a few kinds of each component, since they are ordered in bulk, and the slight variations in hardware revisions should not be much of a problem, but that's still a huge load of work, and it will take time.
Plus, if any machine just so happens to be offline, as in "completely disconnected", its data will survive. The same goes for any disks that happen to be taken out at the moment. The only "safe" solution to that would be to have a small autonomously powered wireless bug on every HDD that will, when triggered remotely, turn on the disk, if it was offline, and order it to go kill itself. Or make it discharge a capacitor into a small flat coil glued to the disk. (Like those stickers that make detectors at shop exits beep at you. It can even have some housekeeping information printed on it, so that there is a reason for it to be there. No one needs to know that there is a coil inside the sticker. The capacitor will still be noticeable, though, unless you hide it under that sticker.)
Or, you know, you could just kill it with fire. But that is outside of my area of expertise.
New contributor
Wow, that is amazingly well thought out. Thank you for the input! :)
– John S.
Nov 28 at 13:09
add a comment |
up vote
2
down vote
Use paper stickers with housekeeping information to keep track of your disk drives!
How would it help? Well, the stickers can have flat coils inside, just like those stickers that make detectors at shop exits beep at you. The coils can do the EMP and degaussing stuff, while also doubling as an antenna for a small control chip. That tiny low-power chip, and the coil, can be powered from a relatively small capacitor, which can be hidden under the sticker too. (Or inside the case, in case of SSDs, as those rarely have big enough cavities on the outside to hide the capacitor in.) The capacitor is absolutely essential in the case that the disk is completely disconnected for maintenance or other reasons when the kill-switch is triggered. It is recharged when the disk is online.
Sticking that coil right to the disk's circuit board should allow for small enough capacitor to kill whatever chips are on the other side with EMP, or to degauss the platters. For SSDs that extra capacitor can also be connected directly to the board instead, frying all the flash chips as soon as the signal comes. Maybe that small controller could also be connected directly to the motor and the heads of an HDD, making it literally scratch out all the data by slowly spinning the platters under unparked heads.
Add a powerful enough wireless transmitter to cover the whole complex, and a big red button (or a small gray one) for the trigger, and you are set! Keep in mind, though, that if someone tears off a sticker and notices a capacitor that's not connected to anything, they might suspect something and take a closer look at the sticker... With that caveat in mind, I think the idea is quite plausible. Someone might have to figure out exactly how big the capacitor has to actually be, but at least for frying flash in SSDs you most definitely can buy powerful enough yet really small caps.
My original idea follows:
Software could, and would in the context of the story, be found and purged.
What about embedded software? Modern computers are very damn smart. Every sizable component has a CPU, be it a network adapter or a microSD card.
Intel AMT allows you to connect to a server remotely and work on it like it's in front of you: a display, a keyboard, you can even "plug in" your hard disk into it over the network. And the best part is, all this works as soon as you press the power button (some of it even before that), and it is completely out-of-band. That last bit means that any software working on this server will never see any AMT traffic, and it will think that you've actually opened up the case and attached that HDD.
Despite having all that functionality, AMT works almost entirely on the motherboard itself, doesn't touch the main CPU or RAM, and is almost invisible to the "main" system. It's code is very obscure, extremely platform-specific and proprietary. Only some very smart hackers managed to get into it (and find a few glaring security holes...), under the normal circumstances no one will ever touch it in any way other than through the official client software from Intel.
Every HDD and SSD has an embedded controller, too. Wiping an SSD "from the inside" is as simple as "forgetting" where the index for all of its flash memory is, maybe wiping that relatively small index beforehand for good measure. And on HDD you can just slow down the platters enough for the heads to land on them and dig trenches all over the surface. (The heads are too weak to magnetically damage the data quickly enough, so physically damaging the surface is the only way.)
All the network hardware also has embedded processors, even the "really" embedded ones in case of bigger devices that are like normal computers themselves on the inside.
What I'm getting at is, most people don't even realize that their microSD card may well be more computationally powerful than a PC from late 90s! No one ever really looks inside those embedded chips. Oftentimes you cannot even read the firmware from them, only flash the updates. (And thus their security is severely lacking oftentimes, except the "Security through Obscurity" kind.)
If some kind of backdoor is installed on that level, I doubt that anyone will ever notice it. At least not until it's exploited and forensics start digging into the chips. No "normal" software will be able to detect that something's wrong, you'd have to take the device apart and dig in with a JTAG debugger to even have a chance.
Let's say that one of the routers in the datacenter receives a malformed packet. It looks like it's a normal packet that got (unnaturally severely) corrupted in transit. Normally, it would be silently dropped, and higher level protocol, like TCP, will request retransmission. Suddenly, the router broadcasts that same packet over all its connections, and then immediately "dies", maybe requiring a firmware recovery procedure to continue functioning. Every server that receives the packet suddenly crashes due to CPU voltage dropping below acceptable minimum, and its disks experience catastrophic firmware failure that destroys all the data in a matter of seconds. A few more seconds later, the "smart" power supply infrastructure, which also received the packet of death, cuts the power to the whole complex. And perimeter routers just receive and drop the packet as they should, not a single bit of suspicious data gets outside.
In just 10 seconds or so, the datacenter inexplicably goes from perfectly fine and healthy to totally blacked out and dead. All the networking infrastructure is lacking any firmware to even work. All the data is lost, either in unintelligible fragments randomly scattered across several flash chips in each SSD, or literally scattered all over the insides of HDDs.
No one has any clue as to what has happened. Even if someone figures out later that the firmware of almost everything in the complex had peculiar bugs that just so happened to act together in such devastating manner, it can still look like it all was an accident. Since there are no traces of the packet that caused the whole mess, the only way someone might figure out that it was malicious is by contacting HDD vendors and finding out that the firmware slightly differs from what should have been there, but even that would be practically impossible to say for sure, due to how much things change internally during product life cycle.
And in that last bit lies the catch. That 'small team' of yours will have to reverse engineer the firmware of every HDD, SSD, motherboard, network card and router in the datacenter, plus the smart power supply system. There likely will only be just a few kinds of each component, since they are ordered in bulk, and the slight variations in hardware revisions should not be much of a problem, but that's still a huge load of work, and it will take time.
Plus, if any machine just so happens to be offline, as in "completely disconnected", its data will survive. The same goes for any disks that happen to be taken out at the moment. The only "safe" solution to that would be to have a small autonomously powered wireless bug on every HDD that will, when triggered remotely, turn on the disk, if it was offline, and order it to go kill itself. Or make it discharge a capacitor into a small flat coil glued to the disk. (Like those stickers that make detectors at shop exits beep at you. It can even have some housekeeping information printed on it, so that there is a reason for it to be there. No one needs to know that there is a coil inside the sticker. The capacitor will still be noticeable, though, unless you hide it under that sticker.)
Or, you know, you could just kill it with fire. But that is outside of my area of expertise.
New contributor
Wow, that is amazingly well thought out. Thank you for the input! :)
– John S.
Nov 28 at 13:09
add a comment |
up vote
2
down vote
up vote
2
down vote
Use paper stickers with housekeeping information to keep track of your disk drives!
How would it help? Well, the stickers can have flat coils inside, just like those stickers that make detectors at shop exits beep at you. The coils can do the EMP and degaussing stuff, while also doubling as an antenna for a small control chip. That tiny low-power chip, and the coil, can be powered from a relatively small capacitor, which can be hidden under the sticker too. (Or inside the case, in case of SSDs, as those rarely have big enough cavities on the outside to hide the capacitor in.) The capacitor is absolutely essential in the case that the disk is completely disconnected for maintenance or other reasons when the kill-switch is triggered. It is recharged when the disk is online.
Sticking that coil right to the disk's circuit board should allow for small enough capacitor to kill whatever chips are on the other side with EMP, or to degauss the platters. For SSDs that extra capacitor can also be connected directly to the board instead, frying all the flash chips as soon as the signal comes. Maybe that small controller could also be connected directly to the motor and the heads of an HDD, making it literally scratch out all the data by slowly spinning the platters under unparked heads.
Add a powerful enough wireless transmitter to cover the whole complex, and a big red button (or a small gray one) for the trigger, and you are set! Keep in mind, though, that if someone tears off a sticker and notices a capacitor that's not connected to anything, they might suspect something and take a closer look at the sticker... With that caveat in mind, I think the idea is quite plausible. Someone might have to figure out exactly how big the capacitor has to actually be, but at least for frying flash in SSDs you most definitely can buy powerful enough yet really small caps.
My original idea follows:
Software could, and would in the context of the story, be found and purged.
What about embedded software? Modern computers are very damn smart. Every sizable component has a CPU, be it a network adapter or a microSD card.
Intel AMT allows you to connect to a server remotely and work on it like it's in front of you: a display, a keyboard, you can even "plug in" your hard disk into it over the network. And the best part is, all this works as soon as you press the power button (some of it even before that), and it is completely out-of-band. That last bit means that any software working on this server will never see any AMT traffic, and it will think that you've actually opened up the case and attached that HDD.
Despite having all that functionality, AMT works almost entirely on the motherboard itself, doesn't touch the main CPU or RAM, and is almost invisible to the "main" system. It's code is very obscure, extremely platform-specific and proprietary. Only some very smart hackers managed to get into it (and find a few glaring security holes...), under the normal circumstances no one will ever touch it in any way other than through the official client software from Intel.
Every HDD and SSD has an embedded controller, too. Wiping an SSD "from the inside" is as simple as "forgetting" where the index for all of its flash memory is, maybe wiping that relatively small index beforehand for good measure. And on HDD you can just slow down the platters enough for the heads to land on them and dig trenches all over the surface. (The heads are too weak to magnetically damage the data quickly enough, so physically damaging the surface is the only way.)
All the network hardware also has embedded processors, even the "really" embedded ones in case of bigger devices that are like normal computers themselves on the inside.
What I'm getting at is, most people don't even realize that their microSD card may well be more computationally powerful than a PC from late 90s! No one ever really looks inside those embedded chips. Oftentimes you cannot even read the firmware from them, only flash the updates. (And thus their security is severely lacking oftentimes, except the "Security through Obscurity" kind.)
If some kind of backdoor is installed on that level, I doubt that anyone will ever notice it. At least not until it's exploited and forensics start digging into the chips. No "normal" software will be able to detect that something's wrong, you'd have to take the device apart and dig in with a JTAG debugger to even have a chance.
Let's say that one of the routers in the datacenter receives a malformed packet. It looks like it's a normal packet that got (unnaturally severely) corrupted in transit. Normally, it would be silently dropped, and higher level protocol, like TCP, will request retransmission. Suddenly, the router broadcasts that same packet over all its connections, and then immediately "dies", maybe requiring a firmware recovery procedure to continue functioning. Every server that receives the packet suddenly crashes due to CPU voltage dropping below acceptable minimum, and its disks experience catastrophic firmware failure that destroys all the data in a matter of seconds. A few more seconds later, the "smart" power supply infrastructure, which also received the packet of death, cuts the power to the whole complex. And perimeter routers just receive and drop the packet as they should, not a single bit of suspicious data gets outside.
In just 10 seconds or so, the datacenter inexplicably goes from perfectly fine and healthy to totally blacked out and dead. All the networking infrastructure is lacking any firmware to even work. All the data is lost, either in unintelligible fragments randomly scattered across several flash chips in each SSD, or literally scattered all over the insides of HDDs.
No one has any clue as to what has happened. Even if someone figures out later that the firmware of almost everything in the complex had peculiar bugs that just so happened to act together in such devastating manner, it can still look like it all was an accident. Since there are no traces of the packet that caused the whole mess, the only way someone might figure out that it was malicious is by contacting HDD vendors and finding out that the firmware slightly differs from what should have been there, but even that would be practically impossible to say for sure, due to how much things change internally during product life cycle.
And in that last bit lies the catch. That 'small team' of yours will have to reverse engineer the firmware of every HDD, SSD, motherboard, network card and router in the datacenter, plus the smart power supply system. There likely will only be just a few kinds of each component, since they are ordered in bulk, and the slight variations in hardware revisions should not be much of a problem, but that's still a huge load of work, and it will take time.
Plus, if any machine just so happens to be offline, as in "completely disconnected", its data will survive. The same goes for any disks that happen to be taken out at the moment. The only "safe" solution to that would be to have a small autonomously powered wireless bug on every HDD that will, when triggered remotely, turn on the disk, if it was offline, and order it to go kill itself. Or make it discharge a capacitor into a small flat coil glued to the disk. (Like those stickers that make detectors at shop exits beep at you. It can even have some housekeeping information printed on it, so that there is a reason for it to be there. No one needs to know that there is a coil inside the sticker. The capacitor will still be noticeable, though, unless you hide it under that sticker.)
Or, you know, you could just kill it with fire. But that is outside of my area of expertise.
New contributor
Use paper stickers with housekeeping information to keep track of your disk drives!
How would it help? Well, the stickers can have flat coils inside, just like those stickers that make detectors at shop exits beep at you. The coils can do the EMP and degaussing stuff, while also doubling as an antenna for a small control chip. That tiny low-power chip, and the coil, can be powered from a relatively small capacitor, which can be hidden under the sticker too. (Or inside the case, in case of SSDs, as those rarely have big enough cavities on the outside to hide the capacitor in.) The capacitor is absolutely essential in the case that the disk is completely disconnected for maintenance or other reasons when the kill-switch is triggered. It is recharged when the disk is online.
Sticking that coil right to the disk's circuit board should allow for small enough capacitor to kill whatever chips are on the other side with EMP, or to degauss the platters. For SSDs that extra capacitor can also be connected directly to the board instead, frying all the flash chips as soon as the signal comes. Maybe that small controller could also be connected directly to the motor and the heads of an HDD, making it literally scratch out all the data by slowly spinning the platters under unparked heads.
Add a powerful enough wireless transmitter to cover the whole complex, and a big red button (or a small gray one) for the trigger, and you are set! Keep in mind, though, that if someone tears off a sticker and notices a capacitor that's not connected to anything, they might suspect something and take a closer look at the sticker... With that caveat in mind, I think the idea is quite plausible. Someone might have to figure out exactly how big the capacitor has to actually be, but at least for frying flash in SSDs you most definitely can buy powerful enough yet really small caps.
My original idea follows:
Software could, and would in the context of the story, be found and purged.
What about embedded software? Modern computers are very damn smart. Every sizable component has a CPU, be it a network adapter or a microSD card.
Intel AMT allows you to connect to a server remotely and work on it like it's in front of you: a display, a keyboard, you can even "plug in" your hard disk into it over the network. And the best part is, all this works as soon as you press the power button (some of it even before that), and it is completely out-of-band. That last bit means that any software working on this server will never see any AMT traffic, and it will think that you've actually opened up the case and attached that HDD.
Despite having all that functionality, AMT works almost entirely on the motherboard itself, doesn't touch the main CPU or RAM, and is almost invisible to the "main" system. It's code is very obscure, extremely platform-specific and proprietary. Only some very smart hackers managed to get into it (and find a few glaring security holes...), under the normal circumstances no one will ever touch it in any way other than through the official client software from Intel.
Every HDD and SSD has an embedded controller, too. Wiping an SSD "from the inside" is as simple as "forgetting" where the index for all of its flash memory is, maybe wiping that relatively small index beforehand for good measure. And on HDD you can just slow down the platters enough for the heads to land on them and dig trenches all over the surface. (The heads are too weak to magnetically damage the data quickly enough, so physically damaging the surface is the only way.)
All the network hardware also has embedded processors, even the "really" embedded ones in case of bigger devices that are like normal computers themselves on the inside.
What I'm getting at is, most people don't even realize that their microSD card may well be more computationally powerful than a PC from late 90s! No one ever really looks inside those embedded chips. Oftentimes you cannot even read the firmware from them, only flash the updates. (And thus their security is severely lacking oftentimes, except the "Security through Obscurity" kind.)
If some kind of backdoor is installed on that level, I doubt that anyone will ever notice it. At least not until it's exploited and forensics start digging into the chips. No "normal" software will be able to detect that something's wrong, you'd have to take the device apart and dig in with a JTAG debugger to even have a chance.
Let's say that one of the routers in the datacenter receives a malformed packet. It looks like it's a normal packet that got (unnaturally severely) corrupted in transit. Normally, it would be silently dropped, and higher level protocol, like TCP, will request retransmission. Suddenly, the router broadcasts that same packet over all its connections, and then immediately "dies", maybe requiring a firmware recovery procedure to continue functioning. Every server that receives the packet suddenly crashes due to CPU voltage dropping below acceptable minimum, and its disks experience catastrophic firmware failure that destroys all the data in a matter of seconds. A few more seconds later, the "smart" power supply infrastructure, which also received the packet of death, cuts the power to the whole complex. And perimeter routers just receive and drop the packet as they should, not a single bit of suspicious data gets outside.
In just 10 seconds or so, the datacenter inexplicably goes from perfectly fine and healthy to totally blacked out and dead. All the networking infrastructure is lacking any firmware to even work. All the data is lost, either in unintelligible fragments randomly scattered across several flash chips in each SSD, or literally scattered all over the insides of HDDs.
No one has any clue as to what has happened. Even if someone figures out later that the firmware of almost everything in the complex had peculiar bugs that just so happened to act together in such devastating manner, it can still look like it all was an accident. Since there are no traces of the packet that caused the whole mess, the only way someone might figure out that it was malicious is by contacting HDD vendors and finding out that the firmware slightly differs from what should have been there, but even that would be practically impossible to say for sure, due to how much things change internally during product life cycle.
And in that last bit lies the catch. That 'small team' of yours will have to reverse engineer the firmware of every HDD, SSD, motherboard, network card and router in the datacenter, plus the smart power supply system. There likely will only be just a few kinds of each component, since they are ordered in bulk, and the slight variations in hardware revisions should not be much of a problem, but that's still a huge load of work, and it will take time.
Plus, if any machine just so happens to be offline, as in "completely disconnected", its data will survive. The same goes for any disks that happen to be taken out at the moment. The only "safe" solution to that would be to have a small autonomously powered wireless bug on every HDD that will, when triggered remotely, turn on the disk, if it was offline, and order it to go kill itself. Or make it discharge a capacitor into a small flat coil glued to the disk. (Like those stickers that make detectors at shop exits beep at you. It can even have some housekeeping information printed on it, so that there is a reason for it to be there. No one needs to know that there is a coil inside the sticker. The capacitor will still be noticeable, though, unless you hide it under that sticker.)
Or, you know, you could just kill it with fire. But that is outside of my area of expertise.
New contributor
New contributor
answered Nov 28 at 4:04
EvgEnZh
1211
1211
New contributor
New contributor
Wow, that is amazingly well thought out. Thank you for the input! :)
– John S.
Nov 28 at 13:09
add a comment |
Wow, that is amazingly well thought out. Thank you for the input! :)
– John S.
Nov 28 at 13:09
Wow, that is amazingly well thought out. Thank you for the input! :)
– John S.
Nov 28 at 13:09
Wow, that is amazingly well thought out. Thank you for the input! :)
– John S.
Nov 28 at 13:09
add a comment |
John S. is a new contributor. Be nice, and check out our Code of Conduct.
John S. is a new contributor. Be nice, and check out our Code of Conduct.
John S. is a new contributor. Be nice, and check out our Code of Conduct.
John S. is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Worldbuilding Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworldbuilding.stackexchange.com%2fquestions%2f131364%2fwhat-size-emp-device-would-be-necessary-to-wipe-all-data-in-a-google-sized-serve%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Comments are not for extended discussion; this conversation has been moved to chat.
– L.Dutch♦
Nov 27 at 23:50
1
To clarify, you're asking about a single server farm, not all of them? ( Google undoubtedly locates their servers in various physical locations. Are you just wanting to take out one farm it all?). That's also not to mention backup/redundant servers.
– BruceWayne
Nov 28 at 0:55
1
Sometimes I feel like worldbuilding.SE is full of terrorists who are trying to crowdsource the plans for their evil deeds...
– Kapten-N
Nov 28 at 7:37
Well, you could replace the moon with a magnetar. That would probably kill everyone, but would wipe every hard drive in the world and would leave buildings and physical servers intact.
– forest
Nov 28 at 10:17