"The best and the brightest" is such a strange phrase. Whenever I read it I always think of Halberstam and assume the author is using the phrase pejoratively.
1) .gov aka "G-job" means you can't talk about it, maybe even to your boss. Maybe you're making the left support bracket for the Manhattan project, no one in 100 miles knows what you're actually building. Maybe no one knows everything about the whole program. So you're kinda on your own in the machine shop, kinda.
2) Wanna build a model steam engine at work? Tell them the crankshaft is a classified part for some contract you can't talk about and they're not cleared to even see the blueprint.
3) But screwing around for fun doesn't have to be made to the tolerances for real a-bomb parts... So "close enough for govt work"
The other story I heard from oldtimers who were there, was there was an intense push in the early 40s to shovel as much out the door as possible. An automobile plant used to selling to rich dudes wouldn't dare ship a car with cosmetic issues, but tank crews don't care if there's a little weld splatter on the outside or runs in the paint, as long as it actually works in combat. And this created attitude issues when they converted back to making fancy cars for rich dudes after the war. "So there's a giant dent in the hood, the GIs don't care... Uh, yeah but we're not building jeeps anymore..."
It used to be a complement IIRC: the US government set standards which were much tighter than those which were usually acceptable in the commercial world at the time & enforced them. If your work was "good enough for government work" then you were holding yourself to a higher standard than the norm for commercial manufacturing at the time.
If you do a google ngram search on the phrase, you'll see a blip during WWII and then nothing until 1970. I'm guessing the use from 1970 onwards probably carried the negative connotation we're all familiar with.
If you were building a system with legacy firmware (so, for examole you couldn't rotate keys in case of a breach), how would you mitigate against situations like this? Can anyone give a brief overview of how to architect a more secure system?
When you build a public key into firmware which isn't easily updated, you need to put a lot of effort into securing the corresponding private key. The correct way to do this is to have a separate credential for your actual admin users who then use that to authenticate to an HSM or similar system which controls the actual widely-deployed keys. Humans should never be able to access the important private keys directly, and there should be a logging process which shows those keys have never been exported (and have technical and policy controls against being exported) without proper multi-party control (so, you back them up in k of n shares, and distribute those shares across corporate officers in multiple sites in the event you need to replace the HSM).
Shorter lived keys and more frequent updates, provided you also have a secure way of authenticating the updates (hard) is often preferred.
The "canonical" way of solving this is of course with a certificate hierarchy. You can configure your target system to allow authentication whenever your certificate is signed by the "golden" key, and by creating the certificates with expiration dates it's easy to restrict the time that a certificate (which maybe got stolen or was made public inadvertendly) can be used for login.
Adding auxiliary data (comparable to X509 certificate usage restrictions only for code-signing or signing for emails) would allow you to have a (central hardened) machine hand out certificates to your "semi trusted" administrators that only allow login from a specific IP-address, to a specific target-system, up to a certain date or even time. Putting this functionality in a script (to acquire the certificate and login to a system) such a wrapper could most likely be used as a drop-in replacement for the normal ssh-client.
If your restriction is to use only the default openssh already deployed to the target machines, one quick solution to hide the critical private key from the developer/admin/service machines would be to place it on a (hopefully somewhat hardened) machine running the ssh-agent, and access the agent by creative use of tunelling. In essence then the hardened machine would act as a kind of "smartcard" for all your admins.
You can put the private key on a few HSMs, and have the HSM enforce a security policy (eg - access must be authorized by a quorum of operators). Never allow the private key to leave the HSM, ever again, except when initializing a new HSM (in which case, it had better be encrypted by the new HSM's unique key before leaving the old one).
A quick sum of all the incidents in there adds up to 22 million health care records lost so far. It's hard to imagine the government could do much worse.
And yet somehow, in general, national health services with highly integrated medical data storage systems across Europe don't seem to lose data as often as you'd think.
FTA:
Stations that use vulnerable gear should upgrade to version 2.0-2, which is available by sending an e-mail to suport@digitalalertsystems.com.
As a "broadcast-emitting-messages-company" admin: would I really upgrade a system, which functionalities include complete take-over of my broadcast equipment, that is vulnerable to someone mistaking the private and public ssh keys of his "taking-over-any-equipment" equipment ?
I'd rather un-subscribe from that "service" in the limit of legality until that point of failure is fixed.
It's sad that it was abused to broadcast a prank (that might send phobics over the edge) rather than something to enlighten those who don't frequent sites like this one about the current situation with regard to SWIFT, the NSA, and the associated dangers of the situation. Most of the people either aren't aware of it at all, or are focused on Snowden (thanks to CNN, et al) and ignoring or are otherwise oblivious of the huge problem that he exposed.
Far too many don't think for themselves and believe that it's actually a good thing, that it won't/can't be abused, and that it's entirely to fight terrorism. These same people believe that terrorism is an enormous threat (bigger than being killed by drunk drivers, smoking, and bathtub drowning). Sadly, I know plenty of people that fit into this category.
EAS has so many weaknesses, I'd actually qualify this as the least worrisome. The way we deploy any computerized equipment that is a part of our air-chain includes firewalls and only allowing connections to the necessary servers for CAP type alerts.
Every EAS receiver is typically monitoring other stations in the area for EAS relay. We actually have a tuner tuned to another station in the market and if we hear an EAS alert go across the air on their station we simply relay it. Due to the FM capture effect, it's _very_ easy to attack this channel; especially because there's _zero_ authentication on these incoming "relay" messages.
Even worse, some types of messages are setup for "national relay." This system was tested recently to ensure that a message could be relayed like this from one end of the country to the other -- and yes, it can. So, if you construct the right type of message, you can have it broadcast over _every_ station in america.
I wrote a SAME FSK encoder in Java. It was very straightforward. If I had a transmitter, I could have strolled by the local TV or radio station and caused the entire state of Indiana to declare a hurricane emergency.
Relayed across radio stations, TV ticker, and your weather radio.
Clearly, there should be laws mandating that everyone who knows Java, has visited that Wikipedia page, or walks outside radio stations be surveilled at all times, to ensure people's safety.
"be surveilled at all times" We already are, everybody.
Its worse than that, unfortunately. About a decade before SAME started showing up on public for profit broadcasters, they had it on NOAA weather radio (you know, 162.4 MHz and several other channels in that area). So this has been around since the late 80s or so.
Well my bright idea was to latch on to the then popular craze in electronics magazines of make a project using a (then new) PIC, convince a magazine to run the article, sell my pre-programmed PICs to people, and retire to a private island (LOL... but I probably could have made my programmer pay for itself, at least). So I had a PC/AT class machine with a soundblaster 16 generating SAME codes using, if I recall, a BASIC program. The plan was a simple zero crossing detector and what amounts to a software "bit banged" UART and some UI code to drive a LCD module. Back when the PIC16 family was "new" this ended up not fitting, or at least my UI would have been ridiculously crude with little translation and filtering features so I dropped the whole thing. I could fit a really good UI in there or the decoder but not both and I didn't think a multi-chip solution fit the "standards" of the time. Now a days this would be a one chip PIC probably on an arduino shield with real analog input instead of zero crossing detector and all that, and enough space for a monster UI probably. The "target market" at the time was ham radio equipped storm chaser type guys who wanted a SAME radio for "them" rather than for fixed locations. Very travel and location oriented. Now a days of course they just use a smartphone and an app like proweatheralert or just the weather.gov webpage. I don't know if there's a startup lesson buried in here other than its possible to come up with an idea that greatly exceeds the technological limits of the day, not just at the super high end like big data, but also at the super low end.
Anyway the point is you'd have to ban virtually any post 1980's era stuff, including at least some pre-PC era home computers. A PC XT with an original soundblaster should be sufficient to encode SAME tones, its not like I was stressing out my old spare 286 while encoding test tones for my PIC based decoder.
The general development plan of a SAME encoder is about the same as a morse code sender. If you can figure out one, you can figure out the other. So you make a tone generating function. (and for SAME you need two tones, no big deal). Then you send the proper length of each aka a 1 bit transmitter. Then a function to send a whole byte at a time (big endian or little endian?) aka a 8 bit/1 byte transmitter. Then a function that eats a string and calls the byte sender for each byte of the string and optimistically stops when it hits the end of the variable length string. Then a function that eats some vaguely "human compatible" API and squirts out a line of SAME which is fed to the function above. And a zillion subroutines/function calls later, you get an audio SAME message. Making something that sends morse code is developed about the same way.
Its noob-compatible. No need for recursion, scalability is irrelevant, etc. As I recall the ancient PIC16 series didn't do recursion very well at the assembly language level.
It was a detailed technical ramble about how I made a SAME encoder using 80s era hardware and software because I was poor in the early/mid 90s because I was trying to "startup" a little hardware project to sell a mobile car SAME decoder optimized for storm chaser people (and more likely electronics fiends in general). The whole market segment has pretty much been replaced in the 2010's by smartphones and 3G networks so I'm not exactly worried about giving away my idea.
Turns out the encoder was really easy to make using 1980s era stuff, but the tech required to pull off the decoder product greatly exceeded the technological/economic limitations of the time, so that's why the project failed. Oh well.
The point was a raid to eliminate fancy Java and GUIs and modern computers won't stop forbidden SAME encoders from being written, they'd actually have to raid and confiscate museum pieces.
It would be like trying to forbid DES-56 by getting rid of everything DES-56 capable. That's a lot more than year 2012 quad core pentiums, that includes my 25 year old HP-48 calculator...
Another interesting note is that I'm sure the security theater guys would like to calm people by claiming it takes millions of dollars and dozens of people and years of effort and top of the line modern high tech stuff to make a SAME encoder, but I did it alone as a poor yet smart kid using junkpile stuff decades ago in a ridiculously short amount of time. The only reason this doesn't get hacked on a regular basis, is despite the paranoid delusion that they're all out to get us, they actually are not, because they would have gotten us a zillion times over already, if "they" actually wanted to, which they obviously do not desire to do. Some lower forms of humanity profit off convincing people to be hostile toward each other, nothing new there.
Thank you very much for your stories! I agree, it is quite easy. A transmitter for the VHF FM band that EAS uses is fairly simple to construct. I was really, really surprised at the lack of authentication combined with relaying mandated by law. I'm glad I'm not the only one who was concerned!
Oh for fuck's sake. I hope Ars screwed up that email address. Sometimes I feel like regulatory capture has totally screwed our national defense.
I'm from Maryland. I know a lot of defense/NSA people. Some are fantastic. Others... let's just say not everybody is the best and brightest.