|
The implementation of safety and security features in embedded
applications is becoming a key topic as fail-safe and security
technologies migrate to applications well away from the traditionally
security- and safety-conscious military-aerospace and automotive
sectors.
At one time it may have been acceptable to leave application
code and data unsecured on the basis that an embedded system in
question stood alone on a controlled geographical site, which nobody
would go to the trouble of hacking. The realization has come that
hiding "in plain sight" by simply being one of millions of unsecured
installations is becoming, if not unacceptable, decidedly risky.
The implementation of safety and security features in embedded
applications is becoming a key topic as fail-safe and security
technologies migrate to applications well away from the traditionally
security- and safety-conscious military-aerospace and automotive
sectors.
At one time it may have been acceptable to leave application
code and data unsecured on the basis that an embedded system in
question stood alone on a controlled geographical site, which nobody
would go to the trouble of hacking. The realization has come that
hiding "in plain sight" by simply being one of millions of unsecured
installations is becoming, if not unacceptable, decidedly risky.
Embedded applications are all on the network now. "With
networking comes great functionality and flexibility, but also great
responsibility," said one attendee at the 2008 Embedded World
exhibition and conference. The show highlighted numerous approaches to
providing security and safety "from those focused on software,
operating partitions and virtualization, to hardware-oriented
architectures." Nonetheless it is often the traditional safety-critical
applications, such as automotive, and secure applications, such as
smart cards, that provide the technology for deployment elsewhere.
Automotive protocols
One example is the FlexRay
time-triggered protocol for automotive drive-by-wire applications. The
protocol, launched in October 2003, is now presided over by a
consortium that includes Freescale Semiconductor Inc., BMW,
DaimlerChrysler, General Motors, NXP, Robert Bosch and Volkswagen but
there is now discussion of applying the protocol to other sectors.
"Aerospace is interested in the Flexray protocol and there are
discussions about whether Flexray should be opened up. Although it's
not yet open to industrial applications," said James Stuart, a
marketing manager in the MCU division of Freescale.
A time-triggering architecture is considered a key to reliable
operation of such safety-critical systems as drive-by-wire, adaptive
cruise control, collision avoidance and active suspension. It is clear
that aerospace systems could also make use of safety-critical
subsystems to protect, engine systems, and landing gear, but such
safety technology can also be deployed in some transportation systems
such as railways.
However, one objection raised by some attendees at the
exhibition is the distance remit for Flexray which stands a few tens of
meters. Full-blown industrial bus systems must normally be capable of
deployment over hundreds of meters.
It is notable that if FlexRay does gain traction as a more
broadly used bus protocol it will be following the path of CAN and LIN
which both started off in the automotive domain before becoming reused
in industrial applications.
Christian Pfeiler, business development manager, with TTTech
Automotive GmbH acknowledged that there is discussion going on within
the Flexray working groups but said that the use of Flexray in
industrial applications was not going to be an easy or automatic
choice. "CAN is migrating to replace numerous smaller fieldbuses, but
'industrial Ethernet'
is already doing much of the work." Pfeiler acknowledged that there are
many flavors of industrial Ethernet but pointed out it is possible to
layer a time-triggered protocol onto industrial Ethernet. "It combines
office data, with secure data and safety on the same network at the
same time," he said.
But while a time-triggered protocol can provide deterministic
delivery times for messages and control signals as part of a
safety-aware design, it does not, of itself, provide security of data
or program code. But Freescale for one is providing hardware assistance
for cryptography on a broad range of its industrial MCUs and
microprocessors with Ethernet.
"We have internal activity going on in a safety and security
project," said Pia Huesch, a field applications engineer manager for
Freescale.
Secure with hardware
Renesas Technology Corp. is
introducing an initiative called R-Secure, which is making use of the
security features found in the company's smartcard MCU chips. Renesas has been in the smartcard MCU business for 15 years and reckons itself to be number two behind Infineon.
Vincent Mignard, marketing engineer with Renesas Technology
Europe GmbH said that there is a growing awareness of the need for
security and that it has to be addressed at some point in hardware. The
Renesas R-Secure initiative plans to take the Renesas 16bit smartcard
MCU core and integrate it with application-specific peripherals and
software to address particular markets.
"The first application is power metering. At the moment there
is almost no security but most of the utility companies have plans to
introduce powerline communications to collect usage data. Customer data
is sensitive," he said.
Mignard said many utility companies plan to build out from
basic metrology to offering security and safety services to customers,
such as the ability to detect unusual usage or lack of usage which
might signal a problem in an elderly person's home.
Authentication and anti-counterfeiting is another business
opportunity for R-Secure, said Mignard pointing out that it could be
worth fitting a unique identifier to prevent counterfeiting to
something as simple as a printer cartridge. So far, Mignard said,
Renesas was only addressing the smart metering application and adding
serial buses such as SPI rather than Ethernet. Mignard said the
R-Secure initiative could move out to certain automotive applications
in time.
Core safety
ARM Holdings plc (Cambridge, England)
also has experience of adding security to the cores it licenses to
semiconductor companies. ARM offers a dedicated series of cores for
smartcard applications, such as SIMs, and its TrustZone technology to
support secure data for financial transactions on mobile phones.
Haydn Povey, product manager for deeply embedded CPUs at ARM,
took a different position saying that although there is a greater
awareness of security in networked embedded applications, and moves
from 64bit encryption to 128bit, that security is often catered for in
software. Povey said ARM licensees had benefitted as this had driven
many embedded applications from 8- and 16bit MCUs and on to 32bit
devices.
"Designers often use hardware at first but then the technology tends to move back into software," said Povey.
Mignard protested that everything could not be done in software. "Where do you store the codes, the keys, the secrets?" he said.
Gaisler Research AB of Sweden is another example of a company
carrying the seeds of security and fault-tolerance from aerospace to
industrial applications. Jiri Gaisler founder and CTO of the company,
developed Leon, a Sparc-compliant 32bit processor, while working for
the European Space Agency, where the Sparc architecture is mandated for
all European space projects. He founded Gaisler Research in 2001 and
continued to supply early versions of the Leon on a royalty-free
open-source license. Gaisler Research now offers the Sparc v8-compliant
Leon-2 and Leon-3 cores.
"Now 60 percent of our customers are non-aerospace," said Per
Danielsson, president and CEO, "And about 10 percent of are asking for
fault tolerant and fail-safe support." Danielsson said that the company
can provide encryption support for Advanced Encryption Standard (AES)
and Eliptical Curve Crytography (ECC) through additional hardware
blocks.
However, Danielsson said there is much interest in
safety-critical technology, particularly Gaisler's aerospace experience
in single-event upset (SEU) and proofing systems against it. An SEU
occurs when a high-energy particle strikes a transistor gate or memory
node causing a voltage spike and a flow of electrons that can flip
bits. While a change in a memory value may be corrected by paritybit
methods, or may not matter very much were a pixel color value in a
multimedia stream is changed, such bit-flipping could be disastrous for
safety-critical software.
The likelihood of such events happening is relatively low at
sea-level compared with at altitude, but is increasingly likely as
transistor sizes diminish. "At 65nm you start getting sensitive to
single-event upset. Although the likelihood of any one system being
effected may be low if you've got millions of cars on the road, each
with multiple ECUs, the likelihood that one will be effected is high,"
said Danielsson.
To emphasize the risk he said that a laptop computer left
running on a transatlantic flight at 30,000 feet was likely to
experience many SEU events and crash at least once. There are methods
developed in aerospace, such as triple redundancy, but they are
expensive.
Extra pipeline stage
"The trick is to correct errors
without losing performance," said Danielsson. To that end Leon has
introduced an extra pipeline stage to perform a check on instruction
and data words. In this way the checks are only done on words as
required and without a great performance hit or the introduction of too
much latency.
Elsewhere at the show there was a noticeable emphasis on
software development which also plays its part in safety and security.
Lynuxworks Inc. announced an upgrade to its LynxSecure hypervisor
software and Green Hills Inc. exhibited its Padded Cell Hypervisor.
But while such OS vendors may make claims for multilayered
software stacks full of checks and balances it is the position of
Pfeiler that complexity is always likely to be an issue.
With its knowledge of time triggered protocols TTTech has
already moved into applications in aerospace, railways and off-road
vehicles. "Safety is big in the future of cars. Code size is getting
bigger and a car is like a fighter plane used to be."
"It is a trade off. You can use less safe communications and
put a lot of code on the computing nodes to check for safety." It could
be 80 percent safety code and 20 percent payload, Pfeiler said. "But
that can mean megabytes of code per node and more chances of error. It
can be beneficial to reduce complexity by pushing these things down to
the networking layer."
Read the original article: http://www.eetasia.com/ART_8800508596_480800_NT_38478cca.HTM
|
Get Informed 
Subscribe to this comment's feed
Show/hide comments