I grew up in the snowbelt of upstate NY, and like most kids was subjected to many a boring winter day study hall in high school. It’s 1978. Way before the Sony PS Vita, and before the iPad now threatens to kill off all handheld gaming units, there was Coleco Electronic Quarterback. It had a simple LED grid representing the playing field, and a few buttons that would let you run plays by moving the dot representing the player.

Those things were banned during school hours nearly instantly for their annoying beeping. Teachers relished busting kids trying to sneak them in, even when they tried to play with the sound off.

But calculators were another matter, entirely, and I was armed with my prize possession: a Texas Instruments TI-59. So, I wrote a football game simulation, which used numeric play inputs from 1 to 99, bounced that off some seeding numbers to compute the success of a play call, and tracked down, distance, and score. Game on.

Eventually, one of my friends started beating me regularly. It didn’t take long to discover he was pulling up the registers storing the offensive play input, and he’d gotten enough of a feel for the algorithm to call good defensive plays and generate turnovers. Fail.

Had I heard of Dr. Whit Diffie, I’d have been smarter and hashed the seed and the play inputs, making things more random and encrypted so even if they were read the results wouldn’t be predictable. Instead, we installed a play clock rule so the defense didn’t have time to read the several registers and make a decision, reestablishing the trust and fun that way.

Today, the stakes are a lot higher with the Internet of Things, but the problem is the same.

At the high end, ARM, Freescale, Intel and others are integrating trusted platform features to address things like secure boot and security monitoring. But at the low end, there are a whole lot of microcontrollers out there. There are TPM microcontroller units, but they’re not the mainstream. On most MCUs there is stuff largely sitting out in the clear, or able to be reverse engineered. Security is the last thing most designers thought about in decades of designing with MCUs. Not much has changed, from the legions of 8051s to the latest ARM devices:

ARM Fail: New ARM IoT chip - The word "security" or "crypto" appear nowhere in their announcement. http://t.co/WXWu0Bhc

March 13, 2012 11:35 am via LinkedInReplyRetweetFavorite

@wurtis

Kurt Stammberger

Yes, attacking a single low-value device is a seemingly low return proposition. Consider that device as part of a much larger network, connected to the world via Wi-Fi, or connected to a device that is via Bluetooth, or a similar wireless sensor network connection. If every infusion pump in a hospital, or every Ford anti-lock braking system, or every Boeing 737 somehow were infected, it’d be bad. Even if such an event didn’t actually present a life threatening situation, an outage could mean a huge maintenance hit and loss of services.

Trust declines, rapidly, when security is overlooked and a device is compromised. What if millions of them were compromised, or suspected, all at once? If we’re going to trust the Internet of Things, security will need to make some significant advances at the microcontroller and WSN level, without sacrificing things like battery life. It’s not just an issue for high-end microprocessors and major operating systems.

What are you seeing with today’s embedded development practices and the changes connectivity brings to thinking about security? Is security hype or a real concern for you? How do your teams deal with it?

The good news from this past week’s Smart Grid Security Summit was a consensus we now have the technology needed to enable the smart grid. It’s just the start, however.

The better news – because on the other side of problems lies opportunity – is the technology is not integrated, scaled, or secured enough. Also, in the quest to develop better connections with consumers, social media is coming to the forefront.

Integration is still a challenge. At the lowest layer, we have the basics of sensors and networking in place. I asked some folks about standards, and their not-so-in-jest response was: “Which ones?”. That will sort itself out soon, it always does as architects converge. At the next layer, there are folks asking vendors for interoperability testing, but until utilities line up around at least a baseline of common functionality plus some value add unique to their system, it’s hard to deliver that. As one person put it: “Nobody will pay for someone else’s functionality, but they won’t pay if they don’t get theirs, either.” The idea is folks have to converge on a set of stuff and stop asking for a complete whiteboard, full custom solution.

Scalability is a big issue – it’s the same issue people term “big data” elsewhere. Although the data from a single sensor on a device, be it a smart meter, or something in the distribution or generation network, isn’t a lot or very high bandwidth, there are millions of points each utility is dealing with. The in-vogue solution – the cloud – isn’t exactly a solution in some folks eyes. For instance, the compliance types are asking where, exactly, is the data stored? Do we know it’s there? Can we retrieve it, physically, in case of an audit or other need? If you build a private cloud using your own resources and understand the architecture, you might be able to answer that question. If you outsource cloud services to someone, that’s much tougher to answer.

Security is never absolute, as speakers at the conference have reinforced many times. We have the basic pieces of cryptography, although there are important efforts to get it on much lower power microcontrollers. One burning issue people are working on is key management. There are many aspects people are worried about: creating keys securely and being sure nobody can hack that and create their own is just the start. Getting keys on devices, then getting that device on the grid in the right location and verifying it and it’s configuration is next. Preventing unauthorized devices, maybe even ones with legitimate keys but showing up in unexpected spots, is another layer. There is no framework for key management right now – it’s totally ad-hoc. The standards bodies are gathering to try to put their arms around this one. This also brings items like new, much more sophisticated network mapping tools into play.

Image courtesy East County Magazine

In parallel with those three issues, there are the continuing issues related to consumer privacy, which can’t just be mandated with policy but has to be put in place with people in the loop. People are starting to ask what “data on the move” – on mobile devices – really means. There’s also a sense that social media can really help. The recent SDGE outage, caused by a major glitch in a transmission line feeding San Diego from Arizona, was handled smoothly in part because information flowed from the utility to consumers and their mobile devices over Twitter and Facebook. I’d classify that as an important piece of the smart grid moving forward.

These were the major issues, and there were a lot of great security-specific ideas at the conference. This is actually a teaser for some exciting new content coming soon. You’ll be able to see many of these issues discussed in one-on-one videos we did at the conference with an array of guests from utilities, vendors, and agencies – for now, food for thought. What other opportunities do you see in developing the smart grid? Are these the right issues of concern that merit effort?