Posted by: Tdudeguy
The United State Military chose to not encrypt the video images sent from drone aircraft. They are surprised that enemy fighters would intercept the images, to avoid being surprised themselves.
And we’re all shocked and incredulous. Why? We should expect these kinds of security shortcuts. Let’s dig in a bit deeper and see what other forces are in play.
The design for some drones goes back nearly 20 or so years ago. At that time, the government actively surpressed learning and using encryption technologies, prefering to shovel DES and SkipJack at U.S. This did many things, including supress knowledge of encryption and how to apply it well. I’m not surprised that adding encryption would seem a large hurdle to product development and would be skipped.
In the early 90′s, satellite communications were esoteric, with the Internet a reseach tool only. It seemed ‘safe’ to assume that these channels would never become 1) widely used and 2) an Achilles heel to routing the communications securely. Ethernet bridges cost thousands; no one has access to these networks, let alone can decode the proprietary communication protocols.
(Remember when our vendors upheld the value of proprietary anything? Data formats, communication protocols, even computer chips were perfectly secure because they were–P r o p r i e t a r y! It’s an incantation for quick success. Try it, “I like proprietary encryption. I want a proprietary set of shoes.” Feel the sense of security wash over you!)
Last, the overall design is embedded electronics, and embedded electronics are expensive. Anything embedded must be environmentally hardened; and onsite storage and CPU power needed to encrypt a datastream was monsterously expensive then. So security was not given serious attention. It was too expensive. “Besides, our back-end networks are some of the latest technologies,” they may have mumbled in 1994, “They’re PROPRIETARY!”. Remember when you had to buy an IP stack for Windows?
Now flash forward, with the same design. People have grabbed unencrypted satellite communications for more than a decade. Any planned use of IP networks lacking encryption is met with $300 laptops that have ethernet built in, with Internet access capacity that once cost thousands of dollars a month. What’s the plan now? “Maybe they won’t notice!”?
Embedded computers are pervasive. They are difficult to develop because many are still custom hardware designs with little mass production involved. They are coded up with ‘Git-er-Workin’ C code that loves the most legacy, least secure functions in too many cases. Bounds checking? Ha! Client input sanitation? Not in the specs. Yet now our cars and appliances begin their steady march to Internet connectivity, much as PC’s did in 1993.
I get all of this information from the news and from experience with those old automation controller cards that worked via BASIC programs. As part of my MVP award, I’ve taken a long look at embedded linux and Windows CE both. I’ve even gutted controller code for my old WAP, only to see my root password encoded as a plaintext string!
In all of these cases, I think it’s more surprising that people are shocked. Wow, who knew that a whole batch of mission-critical embedded electronics were sent into the field without adequate security–in the early 90′s.
We wouldn’t do that today would we? Remember the F-22 and all the problems it had? Check this old post out: http://mae.pennnet.com/articles/article_display.cfm?article_id=100159.
No the news talkinghead reports that it will be expensive to retrofit encryption onto that legacy design. No surprise. Unlike coding with a type-safe language like embedded Java (or my fav’ .Net Compact Framework); this is mean-green C code that might be procedural if we’re lucky. Most likely it’s coded to the hardware vendor’s API’s. Extensibility? Nah, not with embedded. Your next mobile phone design will use an entirely different processor and require wildly different calls. You code that one in 60 days. Nah, this is embedded ‘Git-er-Workin’ at its finest, done without .Net Compact Framework’s hardware abstraction layer.
Let me guess, they’ll implement encryption on the drones by using discarded SkipJack chips, soldered onto some daughtercard you put in the design’s slot on the PS/2 motherboard. Ummm, smell the proprietary!