One of the defining characteristics of the new pervasively connected computing environment is that it is still in a state of definition. Two steady states – computing and networking -- have converged and the result is not a third steady state but a still chaotic one.  

As movement toward the new steady state occurs, the relationships between entities in it are still in flux, where changes in one often impact others, and where there are many unknowns to be investigated and questions to be answered.  

Typical of this cascading of effects is the impact of both wired and wireless connectivity on microcontroller development and deployment of embedded devices and systems, especially where security is involved. There still seem to me to be many questions to be answered and issues to be resolved, each of which impacts the relationships between connected devices and the technologies used to build them. 

One of the first questions I have is how great is the need for security at the microcontroller level? Since Sept. 11, 2001 there has been a lot of discussion in relation to SCADA (Supervisory Control And Data Acquisition) network systems and how protected much of our manufacturing facilities, power plants, chemical and fuel distribution centers are, since their often highly automated operation depends on the security of numerous connected microcontrollers.  

There certainly are considerable governmental and societal pressures to make this new connected environment more secure.  But  I think that much of the motivation for securing Zigbee and RFID enabled sensors and MCUs will be financial and personal, not imposed by agencies at the federal level, or because of the very real threat of terrorist-sponsored cyber-attacks.  

Within industry, for example, as more systems become roboticized and sensorized, the ability to connect to these MCU-based devices and gather information will for many businesses and enterprises be a compelling argument for integrating them into their security frameworks. Industrial espionage still occurs and breaking in to such connected enterprises to extract information and/or engage in some economically advantageous hacking has considerable benefit.  

And with the average networked house of the present and near future also the home of anywhere from 100 to 400 connected embedded MCUs, there are serious financial and privacy issues to be resolved as well. Even without considering the illegal snooping and hacking, many companies now employ services that gather an amazing amount of  information about systems – and their owners – connected to the Web. 

Unless there are some serious security walls in place, under the user’s control, that block such intrusions, the amount of information about your personal and home life which could be available for all to see is uncomfortable to think about.  

MCU security: what kind and where?

Not clear to me is what kind of connections to the MCUs need to be secured and how, and to what level of protection. And how does this change with the application environment? Even one-way RFID implementations are not immune, since information stealing is not the only damage that can occur.  

For example, I don’t think that Denial of Service attacks -- overwhelming the local controllers tied to the sensors with spurious input data -- are out of the question.  Certainly this would be a major concern for the Department of Defense which is committed to RFID as a way of monitoring inventory. Ditto for Wal-Mart and a lot of the retail chains and many manufacturers of goods. But in the home? WiFi and Zigbee-connected embedded devices, however, raise a number of serious security issues in the home. 

Given the need for pervasively connecting the many MCUs that now inhabit our lives, what is the impact of the increased need for security on their design, their capabilities and their architectures in the future? And how will this change the way such systems are designed and programmed?  

In almost every article I have read and discussion I have had, the same set of compute intensive algorithms are mentioned, with the same underlying assumption that “goes without saying”: if you are going to secure your system go with the best, the various Advanced Encryption Standard (AES), Data Encryption Standard (DES), Triple-DES, etc. specs developed by or for, and often imposed by, the U.S. government.  

The problem with these algorithms is that they are all very compute intensive. According to evaluations by the National Institute of Standards and Technology (NIST), while a typical 8-bit microcontroller could handle the AES algorithm, it would take more than 8,000 instruction clock cycles and about 3,500 for a 16-bitter. Compared to this, a typical 32-bit embedded RISC engine requires between 700 and 800 cycles while a heavily pipelined VLIW machine requires only 100 and 150 cycles.  

So, where performance is not an issue, use an 8-bit MCU. But where the issue is real-time, deterministic operation, incorporating such algorithms into an MCU fundamentally changes the ground rules by which such devices have traditionally been built and implemented.   

For example, at the very least such mandated algorithms could change developers’ choices and buying patterns, forcing them to move to 32-bit MCUs when an 8- or 16-bitter would do if security were not an issue. It will change life for the makers of the controllers, who, in addition to making the MCUs faster to handle the additional compute load, will also have to make them cheaper.  

But are such compute-intensive encryption algorithms always necessary in wired and wirelessly connected embedded devices? There are several I am aware of -- XTEA and Blowfish, for example – that are less demanding of the MCU. And there is also a variety of simple pseudo-random binary sequence generating schemes. Many of them require considerably less memory space and processing power than the more sophisticated algorithms.  

Back to the Future with machine code

To conserve memory space on-chip, many developers have taken one step back in order to take two steps forward and abandoned programming their MCUs in the very C-language for which they have been optimized, at least for the security algorithms. Instead, they write the encryption algorithm in machine code to save valuable memory space for their application code, which they write in C. Talk about back to the future! Some silicon vendors are now providing AES machine code libraries to developers in the same way certain complex DSP algorithms are provided as callable libraries. 

There are other alternatives and work-arounds to this problem, all of which have a cascade of effects on other elements of a design and on other connected devices. These include (1) going to an external memory device, which would make it more prone to physical acquisition of key code information and access to the system, (2) increasing the amount of on-chip nonvolatile memory, (3) hardwiring the algorithms into the chip’s logic gates,  (4) implementing a special security engine as an coprocessor, and (5) going to an advanced process to allow storage of more data. All of these alternatives share a common characteristic: they are more expensive, an important consideration in most microcontroller applications. 

There is also the question of how physically secure many of the nonvolatile flash-, UV EPROM-, EEPROM- and OTP-based devices are, and how protected from physical hacking. To address this issue several companies – such as IBM and Broadcom are developing less physically hackable nonvolatile devices. But considering the still burgeoning growth in the flash market, most connected devices still depend on less physically secure alternatives. Why? Because they are cheaper, easier to implement, and the more secure alternatives are not standard and are often very specific to particular vendors.  

Shifting to a systems solution to security

But maybe the solution to MCU security is to not rely exclusively on improvements in the devices themselves, but by adopting a more system-level solution. Despite the fact that many embedded MCUs are now a part of a larger distributed and connected computing framework, old ways of thinking are slow to change, especially if they work. But the habit of thinking in terms of discrete, point solutions and securing each device may not be the best and most cost-effective way to solve the problem.  

A few companies, such as Broadcom, have already realized that and started looking at each MCU and its security as part of a more differentiated, layered security architecture allowing the development of a much more nuanced and lower cost solution.  

And although cost of implementation was not its aim, many aspects of the DoD’s Multiple Independent Levels of Security (MILS) specification hold the promise of providing the kind of fault tolerant and fault resilient security framework needed for an open, connected computing environment under threat from all sides.   

In both cases, where high levels of security, such as at the perimeter, are needed, tougher, hardier and more expensive algorithms are used. At the core and less sensitive areas, leaner, and lower cost and minimalist security solutions can be employed.  

Cascades of change are still occurring in relation to security in the MCU environment and a steady state with established norms and procedures is not here yet. But as they occur, these changes will be followed closely in this column and on this Web site. And your views, news story ideas and contributed article proposals are welcome here.

iApplianceWeb site leader Bernard Cole is also site editor of Embedded.com and a partner in the Techrite Associates editorial services consultancy. He welcomes your feedback. Call him at 602-288-7257 or send an email.

For more information about topics, issues and technologies mentioned in this story go to the flashing icon in the upper left corner on this page or go to the iAppliance Web Views page and call up the associatively-linked Java/XML-based Web map of the iApplianceWeb site.

Enter the appropriate key word, product or company name to list instantly every news and product story, product review and product database entry relating to the topic since the beginning of the 2002.