Okay, so the immobilizer functionality has been defeated, and the only "harm" is that it makes your car easier to steal. Other than that, it doesn't interfere with your normal use of the car.
I'd be much more worried if they figured out a way to permanently immobilize your car or install a back-door so they could control it remotely at a later date.
If they just replaced the chip - and whatever device it was contained inside (engine block? entire car? let's hope not) with a patched chip or, more likely, a dummy chip that didn't have any purpose other than to say "no, sorry, function disabled" whenever it was asked to do something, that would patch the vulnerability.
Memo to authors who think they will be sued into silence:
Put your pre-published papers in escrow in a country that's out of reach of any potential lawsuits, with instructions that if it is not published by a certain date that they publish it.
Don't try this if you live in a country where you could be locked up for contempt of court for doing this (emigrate first!), and don't try this for state-secret-level stuff like nuclear-weapons-research or you will likely find yourself behind bars or otherwise "permanently silenced." But for stuff like car-safety issues for people who live in relatively sane-legal-system countries, "publication escrow" will probably become the norm for researchers who work in "people will sue me into silence" research areas.
When I made my subtle friendly-jibe at the summary's title, I was pretending to mean "tomorrow" literally - as in "What if energy prices don't soar on August 11, 2015? Will they wait until August 12 or later, 2015 to restart the plant?" Of course not, that would be silly.
My whole statement was a rhetorical response to the/. editor's choice of headline and it had nothing to do with the Japanese energy market.
Japan To Restart Nuclear Power Tomorrow After Energy Prices Soar
So they are going to restart the nuclear plant tomorrow, but not until after energy prices soar (compared to what, today's end-of-trading-day spot prices?).
What if energy prices don't soar tomorrow?
-- Yes, know what the title means in context. But if I can't send a *cough*subtle*cough* reminder to the editors to choose their headlines a bit more carefully, well, then/. might as well be owned by a corporate behemoth that doesn't care about its readers. *cue "oh wait" in 3...2...1...*
Since you are in education, you should be able to get a Windows Server with the required CALs fairly cheap. Run an Application Server and run Photoshop under it. Your main issues are going to be bandwidth, perceived speed (I've never tried doing a room-full of computers running remote-hosted copies of Photoshop over sub-100Mbps aggregate bandwidth), and the potential loss of everyone's ability to use Photoshop if there is a communications or server-side glitch. There's also the issue of getting a beefy-enough server and a big enough Internet pipe to the server so your server doesn't become a bottleneck.
If you can bypass Photoshop or get it to run under Linux somehow, that might be the better approach. At least then you won't have to worry about paying Microsoft and you won't have yet another single-point-of-failure.
I heard about the kidnapping, but I was unaware of the ISIS terrorists raping the kids.
If my information is out of date, then I'm sorry for spreading stale, incorrect information.
Even if that is true, I will make two nit-picky corrections:
ISIS IS THE PEDOPHILE ARMY.
ISIS, or at least the part of it that rapes children, would now be one of at least two "pedophile armies." Using the term "THE" makes me think "What about Boko Haram, don't they count?"
ALL MUSLIM NUTJOBS ARE IN IT FOR THE CHILD RAPING
Assuming you are just talking about the nut-jobs and are not smearing all Muslims,* I still say this is false because most of the nut-jobs are in it for other reasons (ditto nut-jobs of other religions and atheist and agnostic nut-jobs). Even most of those who are just looking for a quick martyrdom-trip-to-"paradise with 72 virgins" aren't looking for the prepubescent kids that a true pedophile dreams about.
*If you are smearing all Muslims, well, there's no point in discussing this further, so please don't.
If there are more than a few isolated false positives Google will have to backtrack.
Also, if this hits the file-traders where it hurts - and it probably won't because if the file-traders are smart they don't care about Google etc. - then they will find a work-around. I can think of any number of work-arounds that would be very hard to counter without greatly increasing the number of false positives.
Has the shooter never heard of the legendary Criminally Paedophilic ISIS Terrorist?
It's Boko Haram that's the criminally paedophilic terrorists. They are the ones who are raping preteen and young teen girls (and boys?) in their war in Africa.
I've been saying for years that computers should have a hardware reset button or (for chips) a pin that restores them to a known factory state. If the button is pressed or the pin is set during initial power-on from a cold boot, the factory reset occurs. Any "infected" code will never get a chance to take control before the reset is finished.
Obviously now I'm going to have to extend that recommendation to any system or subsystem - including the CPU - which can be reprogrammed or save state in a way that survives power loss.
Lean security protocols need to come first, which is why Qubes OS [qubes-os.org] is based on a Type 1 hypervisor (Xen). An attacker can try to use an exploit (like in OP) all they want in an untrusted domain, but they aren't going to get access to the hardware (or the other VMs, unless the user has done something to specifically expose those VMs to the attack).
This assumes there is a security layer that is free of exploitable bugs and that there is no way to influence the lower security layers in a way that can exploit bugs in those layers.
That's a very big assumption unless the security layer you are talking about AND all lower security layers are all so simple that the code can be proven bug-free by inspection.
Back in my student days I had a runaway pointer. On one of mid-1980s Motorola 68000 Macs, it would trigger the power-off function if it wasn't running under a debugger. Talk about frustrating.
At least it was consistent.
Remember, this was back in the days before protected memory. Also, if memory serves, the MacOS and applications always ran in "supervisor mode" (analogous to "ring 0" on Intel chips), so your program 0wned the machine while it was running.
Kind of convenient that they make this sort of "breakthrough" right after Windows NSA edition is given away for "free".
Now now, Windows X isn't any more exploitable by the NSA than most previous versions.
I prefer to call it "Windows Madison Avenue version" or "Windows encourage us to give up our privacy for convenience version" or "Windows get us to pay for Microsoft's bandwidth version".
Well, maybe some of the hardened distros, but your run of the mill distros have so much on them that hasn't been scrubbed from a security standpoint that it makes Windows look merely like swiss cheese instead of confetti.
If you are serious about security but still want a "full featured", not-so-rare-that-almost-nobody-has-heard-about-it, modern OS that runs on and takes advantage of a modern PC, look at either the security-hardened Linux distros, OpenBSD and other security-hardened BSDs, or maybe a custom-stripped-down version of Windows with all unnecessary services turned off AND having it sitting behind a special-purpose, minimalist, hardened firewall appliance. Oh wait, that wouldn't be a "full featured OS", nevermind.
Give the "worst-case" time left rounded to the nearest 15 minutes, with some maximum ("more than 2 hours, but I won't tell you how much more").
By "worst case" I mean the amount of time if the device goes into "maximum power use" mode and stays there until it shuts off.
Oh, and to further prevent profiling, as the battery drains or charges have the "switch over point" to the next "reported" value be slightly off of "real." For example, if it's got 38 minutes left, it will report "30 minutes." But change it to "15 minutes" at some random point between 25 and 35 minutes and, if the device starts charging, change it to "45 minutes" at some random point between 40 and 50 minutes.
Oh, and as for the percentage left, there's no reason for a web site to have that information.
If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.
The value of a one-time pad is that if you can get data securely to someone else only during certain time periods, you can exchange your pads at that time then you can exchange data securely whenever you want to (well, until you use up your pad).
It's really useful when one party, say, a government, is free to "broadcast" the encrypted information, say, over shortwave radio, and the other party, say, a spy, is only a listener. For the spied-upon country to detect the shortwave radio the spy is using will be very difficult, especially if it's in a country where such things aren't outlawed (scratch North Korea). If the spy can sneak into the country with his one-time-pad (say, maybe it's buried in a hearing aid or something) then he's good to go.
The problem with one-time pads is securely exchanging the key and protecting it between the time of exchange and time of use.
If I want to open an account with an online bank or shop at an online store with no local brick-and-mortar location, either I have to drive/fly/whatever out to their nearest location or we have to agree on some mutually-trustworthy person to transport the key between us.
I guess we could agree to transport the key across the Internet, but to do so without weakening security would mean using another one-time pad or similarly-long key to protect the one-time-pad in transit. And around and around we go.
Now, what MIGHT be feasible would be for my bank to ship me a one-time "pad on a chip" that is sealed in a tamper-evident package and have me ship them a different one-time pad in a similar package. The "tamper-evident"-ness of the package would have to be foolproof of course, and there are probably a few other steps I'm leaving out, but you could, theoretically, exchange one-time pads at a distance without having to resort to quantum computers, meeting in person, or particularly trusting your courier. This wouldn't guarantee the pads wouldn't be lost-in-transit, only that they wouldn't be compromised-in-transit.
No, doing things with keys that can either be generated and securely exchanged on the fly or with keys that are public/private is much more practical.
The new quantum-proof version of TLS generates encryption keys using a different mathematical problem that's believed to be beyond the practical reach of both conventional and quantum computers. [emphasis added]
If security trumped everything, those employees would all be retrained and reassigned to completely unrelated tasks and their previous access yanked as soon as their replacements could be trained.
Now, that's not going going to happen except in a relatively small percentage of individuals.
Instead, our country is probably going to take the risk that this info will be used to hurt us rather than pay the cost of losing a valuable employee 21 million times over.
If it's not "I/O gapped" - that is, if state changes aren't completely undetectable outside of the "secure environment" - then for all practical purposes it's not what we used to mean when we said something was "air-gapped."
In today's standards, it needs to be in an EMF-shielded room with an independent power supply (probably batteries), and it needs to be powered down completely when the shielded room's doors are open.
Many corporate, "non-Internet" email systems have had "message recall" and "do not forward" features, but these are there just to "keep honest people honest" - they are trivial to defeat.
Even the most sophisticated systems can't easily defeat the "analog hole" of photographing the screen with a film camera (yes, that can be done - movie theaters do it - but it's not really practical in a non-controlled environment).
Given how few use cases there are like the one you describe, there are probably a lot of important considerations that didn't make it into your question that make your use case unique.
This is one of those cases where you really need to sit down and decide what works best for your situation, NOT what works best for other situations that require this amount of data storage.
Slashdot Mirror
Okay, so the immobilizer functionality has been defeated, and the only "harm" is that it makes your car easier to steal. Other than that, it doesn't interfere with your normal use of the car.
I'd be much more worried if they figured out a way to permanently immobilize your car or install a back-door so they could control it remotely at a later date.
If they just replaced the chip - and whatever device it was contained inside (engine block? entire car? let's hope not) with a patched chip or, more likely, a dummy chip that didn't have any purpose other than to say "no, sorry, function disabled" whenever it was asked to do something, that would patch the vulnerability.
Memo to authors who think they will be sued into silence:
Put your pre-published papers in escrow in a country that's out of reach of any potential lawsuits, with instructions that if it is not published by a certain date that they publish it.
Don't try this if you live in a country where you could be locked up for contempt of court for doing this (emigrate first!), and don't try this for state-secret-level stuff like nuclear-weapons-research or you will likely find yourself behind bars or otherwise "permanently silenced." But for stuff like car-safety issues for people who live in relatively sane-legal-system countries, "publication escrow" will probably become the norm for researchers who work in "people will sue me into silence" research areas.
Now: I promise to resign.
January 2017: Nevermind.
When I made my subtle friendly-jibe at the summary's title, I was pretending to mean "tomorrow" literally - as in "What if energy prices don't soar on August 11, 2015? Will they wait until August 12 or later, 2015 to restart the plant?" Of course not, that would be silly.
My whole statement was a rhetorical response to the /. editor's choice of headline and it had nothing to do with the Japanese energy market.
I'm sorry if I was too subtle.
Japan To Restart Nuclear Power Tomorrow After Energy Prices Soar
So they are going to restart the nuclear plant tomorrow, but not until after energy prices soar (compared to what, today's end-of-trading-day spot prices?).
What if energy prices don't soar tomorrow?
-- /. might as well be owned by a corporate behemoth that doesn't care about its readers. *cue "oh wait" in 3...2...1...*
Yes, know what the title means in context. But if I can't send a *cough*subtle*cough* reminder to the editors to choose their headlines a bit more carefully, well, then
Uranium is more expensive than gasoline per gallon, but you get much more energy out of a gallon of uranium.
*scratches head*
Since you are in education, you should be able to get a Windows Server with the required CALs fairly cheap. Run an Application Server and run Photoshop under it. Your main issues are going to be bandwidth, perceived speed (I've never tried doing a room-full of computers running remote-hosted copies of Photoshop over sub-100Mbps aggregate bandwidth), and the potential loss of everyone's ability to use Photoshop if there is a communications or server-side glitch. There's also the issue of getting a beefy-enough server and a big enough Internet pipe to the server so your server doesn't become a bottleneck.
If you can bypass Photoshop or get it to run under Linux somehow, that might be the better approach. At least then you won't have to worry about paying Microsoft and you won't have yet another single-point-of-failure.
I heard about the kidnapping, but I was unaware of the ISIS terrorists raping the kids.
If my information is out of date, then I'm sorry for spreading stale, incorrect information.
Even if that is true, I will make two nit-picky corrections:
ISIS IS THE PEDOPHILE ARMY.
ISIS, or at least the part of it that rapes children, would now be one of at least two "pedophile armies." Using the term "THE" makes me think "What about Boko Haram, don't they count?"
ALL MUSLIM NUTJOBS ARE IN IT FOR THE CHILD RAPING
Assuming you are just talking about the nut-jobs and are not smearing all Muslims,* I still say this is false because most of the nut-jobs are in it for other reasons (ditto nut-jobs of other religions and atheist and agnostic nut-jobs). Even most of those who are just looking for a quick martyrdom-trip-to-"paradise with 72 virgins" aren't looking for the prepubescent kids that a true pedophile dreams about.
*If you are smearing all Muslims, well, there's no point in discussing this further, so please don't.
If there are more than a few isolated false positives Google will have to backtrack.
Also, if this hits the file-traders where it hurts - and it probably won't because if the file-traders are smart they don't care about Google etc. - then they will find a work-around. I can think of any number of work-arounds that would be very hard to counter without greatly increasing the number of false positives.
Has the shooter never heard of the legendary Criminally Paedophilic ISIS Terrorist?
It's Boko Haram that's the criminally paedophilic terrorists. They are the ones who are raping preteen and young teen girls (and boys?) in their war in Africa.
I've been saying for years that computers should have a hardware reset button or (for chips) a pin that restores them to a known factory state. If the button is pressed or the pin is set during initial power-on from a cold boot, the factory reset occurs. Any "infected" code will never get a chance to take control before the reset is finished.
Obviously now I'm going to have to extend that recommendation to any system or subsystem - including the CPU - which can be reprogrammed or save state in a way that survives power loss.
Lean security protocols need to come first, which is why Qubes OS [qubes-os.org] is based on a Type 1 hypervisor (Xen). An attacker can try to use an exploit (like in OP) all they want in an untrusted domain, but they aren't going to get access to the hardware (or the other VMs, unless the user has done something to specifically expose those VMs to the attack).
This assumes there is a security layer that is free of exploitable bugs and that there is no way to influence the lower security layers in a way that can exploit bugs in those layers.
That's a very big assumption unless the security layer you are talking about AND all lower security layers are all so simple that the code can be proven bug-free by inspection.
Back in my student days I had a runaway pointer. On one of mid-1980s Motorola 68000 Macs, it would trigger the power-off function if it wasn't running under a debugger. Talk about frustrating.
At least it was consistent.
Remember, this was back in the days before protected memory. Also, if memory serves, the MacOS and applications always ran in "supervisor mode" (analogous to "ring 0" on Intel chips), so your program 0wned the machine while it was running.
Kind of convenient that they make this sort of "breakthrough" right after Windows NSA edition is given away for "free".
Now now, Windows X isn't any more exploitable by the NSA than most previous versions.
I prefer to call it "Windows Madison Avenue version" or "Windows encourage us to give up our privacy for convenience version" or "Windows get us to pay for Microsoft's bandwidth version".
Well, maybe some of the hardened distros, but your run of the mill distros have so much on them that hasn't been scrubbed from a security standpoint that it makes Windows look merely like swiss cheese instead of confetti.
If you are serious about security but still want a "full featured", not-so-rare-that-almost-nobody-has-heard-about-it, modern OS that runs on and takes advantage of a modern PC, look at either the security-hardened Linux distros, OpenBSD and other security-hardened BSDs, or maybe a custom-stripped-down version of Windows with all unnecessary services turned off AND having it sitting behind a special-purpose, minimalist, hardened firewall appliance. Oh wait, that wouldn't be a "full featured OS", nevermind.
Give the "worst-case" time left rounded to the nearest 15 minutes, with some maximum ("more than 2 hours, but I won't tell you how much more").
By "worst case" I mean the amount of time if the device goes into "maximum power use" mode and stays there until it shuts off.
Oh, and to further prevent profiling, as the battery drains or charges have the "switch over point" to the next "reported" value be slightly off of "real." For example, if it's got 38 minutes left, it will report "30 minutes." But change it to "15 minutes" at some random point between 25 and 35 minutes and, if the device starts charging, change it to "45 minutes" at some random point between 40 and 50 minutes.
Oh, and as for the percentage left, there's no reason for a web site to have that information.
If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.
The value of a one-time pad is that if you can get data securely to someone else only during certain time periods, you can exchange your pads at that time then you can exchange data securely whenever you want to (well, until you use up your pad).
It's really useful when one party, say, a government, is free to "broadcast" the encrypted information, say, over shortwave radio, and the other party, say, a spy, is only a listener. For the spied-upon country to detect the shortwave radio the spy is using will be very difficult, especially if it's in a country where such things aren't outlawed (scratch North Korea). If the spy can sneak into the country with his one-time-pad (say, maybe it's buried in a hearing aid or something) then he's good to go.
The problem with one-time pads is securely exchanging the key and protecting it between the time of exchange and time of use.
If I want to open an account with an online bank or shop at an online store with no local brick-and-mortar location, either I have to drive/fly/whatever out to their nearest location or we have to agree on some mutually-trustworthy person to transport the key between us.
I guess we could agree to transport the key across the Internet, but to do so without weakening security would mean using another one-time pad or similarly-long key to protect the one-time-pad in transit. And around and around we go.
Now, what MIGHT be feasible would be for my bank to ship me a one-time "pad on a chip" that is sealed in a tamper-evident package and have me ship them a different one-time pad in a similar package. The "tamper-evident"-ness of the package would have to be foolproof of course, and there are probably a few other steps I'm leaving out, but you could, theoretically, exchange one-time pads at a distance without having to resort to quantum computers, meeting in person, or particularly trusting your courier. This wouldn't guarantee the pads wouldn't be lost-in-transit, only that they wouldn't be compromised-in-transit.
No, doing things with keys that can either be generated and securely exchanged on the fly or with keys that are public/private is much more practical.
The new quantum-proof version of TLS generates encryption keys using a different mathematical problem that's believed to be beyond the practical reach of both conventional and quantum computers. [emphasis added]
Okay, now you can "hahahahaha" all you want.
It is based on a mathematical problem very difficult for both conventional and quantum computers to crack.
Ah, that would be my federal tax return.
If security trumped everything, those employees would all be retrained and reassigned to completely unrelated tasks and their previous access yanked as soon as their replacements could be trained.
Now, that's not going going to happen except in a relatively small percentage of individuals.
Instead, our country is probably going to take the risk that this info will be used to hurt us rather than pay the cost of losing a valuable employee 21 million times over.
If it's not "I/O gapped" - that is, if state changes aren't completely undetectable outside of the "secure environment" - then for all practical purposes it's not what we used to mean when we said something was "air-gapped."
In today's standards, it needs to be in an EMF-shielded room with an independent power supply (probably batteries), and it needs to be powered down completely when the shielded room's doors are open.
Many corporate, "non-Internet" email systems have had "message recall" and "do not forward" features, but these are there just to "keep honest people honest" - they are trivial to defeat.
Even the most sophisticated systems can't easily defeat the "analog hole" of photographing the screen with a film camera (yes, that can be done - movie theaters do it - but it's not really practical in a non-controlled environment).
Given how few use cases there are like the one you describe, there are probably a lot of important considerations that didn't make it into your question that make your use case unique.
This is one of those cases where you really need to sit down and decide what works best for your situation, NOT what works best for other situations that require this amount of data storage.