Aerospace & Defense

The Dawn of a Paradigm Shift in Embedded Device Software Security

By Marc Brown

The number of connected embedded and mobile devices is increasing exponentially, predicted to be in excess of 50 billion by 2020.  The lion’s share of this growth is expected to come from traditional market segments where there is an increasing push to transform sensing equipment to more autonomous embedded control, real-time telemetry, and proactive diagnostics. We all know website hacking is nothing new, but just imagine having your public water utility meter, your automobile safety functions, our public transportation traffic sensors, or even the national power grid being hacked by organized criminals or nation states.  This tsunami of connectivity and more intelligent control is creating a huge increase in security vulnerabilities that can impact financial profitability, public services and safety, and national defense. 

Many of today’s most advanced embedded control systems are based on a collection of standalone components – embedded operating systems, virtualization technologies, communication stacks, middleware, and application code.  These standalone products, and the companies that create them, lack the integrated security support required in today’s highly connected world, offering overall solutions that are only as safe as the weakest link. 

McAfee and Wind River have formed a strategic partnership to develop and support comprehensive, purpose-built security solutions specifically designed for these next-gen embedded devices.  This partnership will combine the security expertise from both companies, powering security solutions that support all software layers.  It’s our belief, that it’s time to proactively define and accelerate solutions that protect the functions a device is expected to perform and the data that it accepts from the cloud.

Given the huge liabilities and increased security activity, with over 55,000 new unique malware found on a daily basis, all companies developing embedded products will need to have strategies in place to cope with increasing security requirements.  Only Wind River and McAfee can handle the broad types of security vulnerabilities effecting embedded devices today.  By combining Wind River’s core security-certified runtime technologies, with McAfee’s whitelisting, anti-malware and global threat intelligence capabilities, we’ll be able to support a broad array of connected M2M capable devices for industrial automation, energy, medical, networking, consumer electronics, aerospace and defense.

It’s obvious that security and secure embedded solutions have become a necessity.  It’s also known that cyber attacks, global connectivity, and the associated risks are on the rise, accelerating at a near exponential rate.  Wind River and McAfee have defined something fundamental, something new, on the forefront of embedded solutions, which will solve the growing security requirements and aid in its evolution.  We are no longer in a world only concerned about performance, footprint, and connectivity…the world of highly performing secure embedded solutions has arrived.

 

Domesticated Robotics?

By Mike Deliman

A discussion about robotics was started up in an online discussion forum.  A question was posed to the group:

Will unmanned vehicles eventually see duty in civilian applications?

Technology for unmanned military vehicles may eventually trickle down to commercial applications on Main Street. In the near future, autonomous vehicles will be used to deliver packages, collect garbage and fill potholes. http://bit.ly/bSrqfx

The way I read the question, it asks about unmanned "vehicles" in general.  Without specification I would regard this to include all autonomous robots, all sizes, all forms of motivation (wheels, legs, wings, whatever).

Part of my initial response was...

Given the increasing needs for communication points, bandwidth, and the increasing desire for remote data sensing (think: telerobotic tourism as an eventual end), it is an inevitability that unmanned robotic vehicles will play a significant role in the commercial and private sectors.

Expanding on this some, we are already seeing an expansion in domestic robotics.  Googling for "domestic robot" gets you nearly 58,000 hits!  There are devices covering from vacuums to "butlers" to sophisticated electronic teddy bears appearing in this fledgling market segment.

In the industrial sector, there are mining robots, deep sea robots, welders, archivists, pipe inspectors, and harmful-environments service robots.  Like the home PC market had in 1975, this market has some potential for growth. 

My instincts tell me the real question isn't "will there be unmanned vehicles [autonomous robotics] in civilian duty", but how will we best make use of the explosion of these devices, maximize their safety, provide some level of individual security for the owners/users, and ... make it all work on limited power budgets.

Getting back to the need for connections, your local municipality may begin to employ remote service machines.  These machines may be used (as in the referenced article's question) to maintain the infrastructure, and perform communal duties of domestic maintenance.  These collections of robots will need data channels to convey back the results of their duties, nominal status, and report noted exceptions.  One could foresee a day when semi-intelligent autonomous systems might be used to augment domestic and emergency services personnel.

Could you imagine if your area had some natural disaster, and the local water provider were able to send robotic pipe inspectors through the system to listen for people trapped inside buildings?  Or perhaps your vacuum cleaner reporting that your apartment is on fire while you're on vacation, and which room is on fire?  Though either of these sound a little fantastic, both are easily feasible with today's technologies.  It could easily be done with a mix of a hypervisor and use of existing software on a low-power multicore platform, the rest of it is just batteries, motors, radios, and a fancy box.

The security side of it can come from a mix of approaches and disciplines, depending on what the intended goals of the platform are.  For instance, you don't want intercepted pipe inspection data used wrongly (for industrial espionage, for instance), so the sensor feedback channels could require some form of encryption or pre-processing.

Larger systems / devices might require some form of review by certification agencies.

I don't think it's a question - will there be more unmanned gizmos working for us?  It's a certainty I think, just a mater of time.  I'm wondering how long until they want counted in the census...

A Decade at Wind River

By Paul Parkinson

On Wednesday, it will be exactly ten years since I joined Wind River.

I was thinking about this on my flight to San Francisco on Saturday, and as well as wondering how I long I've spent watching the VxWorks boot loader counting down to zero on the serial console over the years, I was also reminiscing about my early days with the company.

In many ways, it doesn't feel like a decade (as they say: time flies when you're having fun). This is the longest that I've worked for a company, and I was thinking about what it is that keeps me so interested and motivated in my job.

It's hard to put into words, but I have to admit that I really enjoy being at the cutting edge, observing the continual technological advances, not just for technologies' sake (although I admit to being a technophile), but in order to work out these can be applied to real world applications to meet customer requirements and solve their problems.

I started at Wind River in 2000, just before the dot com boom turned into the dot com crash, which many people would rather forget, but this was still a significant point when Internet connectivity was starting to spread from the Enterprise arena into the outside world. In my own area of specialization, Aerospace & Defense, IP-based networking was only just starting to replace stove pipe systems, but the adoption of commercial-off-the-shelf (COTS) technologies was fragmented and interoperability hindered by a lack of standardization. This made presented an unwanted challenge of developing a solutions stack for programmes.

Ten years on, I'm not so naive as to claim that things are now perfect, but the widespread adoption of open standards and open architectures in recent years is providing programmes with a range of interoperable implementation options, increasing choice and flexibility, and also resulting in lower risk for long term support and managed obsolescence.

I've also noticed that embedded devices have become a lot smarter in the last decade, passive remotely controlled devices are now being superseded by intelligent semi-autonomous and even fully-autonomous systems which are capable of flying UAVs and even aircraft without a pilot (see previous blog: Airborne Control of UAV Swarms). A lot of this has only become possible due to the massive increase in processor performance in relation to power dissipation (especially in airborne systems, and with the advent of multicore processors this provides even greater potential for exploitation). I wonder whether in ten years time we will have seen the introduction of autonomous commercial aircraft, maybe for cargo initially?

The Internet has become all-pervasive, and we now rely on IP-based networking for everything from communication between desktop computers, multimedia broadcast, through to critical national infrastructure. This presents new challenges in terms of increased cybersecurity threat due to the inter-connectivity of networks and some of the IPv4 protocols were not designed with security in mind. However, the deployment of IPv6 and the on-going developments of processor hardware virtualisation support and provably secure implementations of the Multiple Independent Levels of Security (MILS) will provide the foundations for secure robust systems which can mitigate this threat and more besides.

A decade on, the future still looks exciting.

Tolerating Delays

By Mike Deliman

This may sound a bit funny, but in the space industry, we're constantly playing catch-up.  We're either looking at or for things that happened millions or hundreds of millions of years ago, sending rockets off to get to where something will have been just in time to take a picture of or bore a hole into it, or designing new rockets for flight 5 years from now with computer bits that would have been considered top-of-the-line 5 or 10 years ago.  When we're recovering data and sending commands from and to deep space probes, we point our antennae to where the probe is supposed to be 30 minutes from now and start sending our data now; the idea is by the time the data actually gets there the craft will be where it was expected and receive the commands, and send it's data back to us.

This process I just described - of anticipating where a craft is, transmitting before it's there - and it transmitting back - is pretty much how the Deep Space network is currently used.  It takes huge amounts of planning, all done in advance, to set up the multiple sessions that allow one successful exchange like that to work out.  People consult tables of times when craft will be "visible", consult tables of one-way light distances to find transmission times.  When they think they know when they need time, and how much data they expect to exchange (how much  time they need),  they contact the folks who run the big antennas.  if the time slot is available, arrangements are made, and that one set of transmissions can take place.  The folks who run the Deep Space Network and their customers do this sort of thing all the time - it's how they try to make the most efficient use of their giant antennae.

Thinking about this whole process, it would seem that you should be able to automate much of it, if not all of it.  There may be some circumstances where manual intervention is necessary, but if much of it were automated, automation might be able to help bringing data back indirectly.  For a given satellite or probe a table could be maintained with information about the DSN and other contact points it maintains regular connections with.  Other probes and satellites could maintain similar tables.  This would enable other deep space probes, satellites, orbiters, and craft for planet exploration (landers, crawlers, flying / roving automata) to plan and create connections as-needed to trade data with each-other.  On top of these communication connections you could layer protocols and methods, and from this, you could create a sort of network.

That is exactly what this article titled Dot Mars is about.  Delay Tolerant Networking, or DTN, is an experimental protocol to enable the internet to reach out off of the Earth.  JPL's Interplanetary Overlay Network (ION) implementation was tested last summer between the Deep Impact / EPOXI satellite and the Deep Space Network.  The test results were: success.

DTN does more than just create another way to move data back from space.  And it's potential reaches into terrestrial applications as well as to oter planets.  The gains that could be leveraged by spacecraft could also be leveraged here.

In space DTN could be a key factor in project design.  If a team knew for sure that the DTN internet was available, and would offload data at regular intervals, they could take advantage of that fact.  If you knew you could send back a set amount of data per day every day, and you'd only ever have to store perhaps a week's worth of data backlog, you could leverage this in your craft's design.  You may be able to design-in less long-term storage, making the craft lighter.  You may have more bandwidth available, so you may decide to use sensors with more sensitivity or take more samples than you may otherwise have planned on.  Returning more data and possibly better data should mean a higher likelihood of a successful mission.  Overall, encorporating DTN into a space project could mean reduced costs and better returns.

Bringing the paradigm back down to earth, DTN could be deployed in a large number of terrestrial applications.  For example, remote sensors currently wait to be connected to and commanded to offload data, or they attempt to send back their data at regular intervals.  If they miss a specific connection it could mean lost data.  If they were able to organize and tap into a DTN style of network, they could possibly offload their data to some alternative trusted node and not have to incur any data loss. 

It could even affect your home life.  Sensors, for example in your car, could store event related data indicating you need the spark plugs replaced.  Right now if you disconnect the battery before a mechanic reads your OBDII data, you'd lose that information.  With a DTN-enabled system, the car's onboard computer could store that data, and tag it as important.  The next time it's near a trusted-node - at home, at work, or perhaps even hile filling-up at a gas station, it could email that data to the owner perhaps allerting them before a breakdown occurs.  Having your car break down at the just wrong time could be an intolerable delay.

Security and cyber warfare

By Paul Parkinson

One of the Christmas presents I received was the book The Edge of Madness by Michael Dobbs. It's a novel about cyber warfare and is set in the present day. Despite mixed reviews of the book in the media (Daily Telegraph, Guardian), I found it to be a gripping read, and finished it over two evenings.

The reason why it held my attention was because of its central theme: the imminent threat of cyber warfare against a nation through co-ordinated attacks against critical national infrastructure (banking, commerce, energy,  telecommunications, etc.) bypassing national defence forces. Although we have yet to witness an offensive on this scale, there have been several instances of international cyber warfare in recent years, so perhaps these can only escalate in the future?

As I read the book, I was trying to distinguish between those scenarios which were accurate and/or technically feasible, and those where the author may have used artistic license. However, when I did a bit of research afterwards, I found that I had some misconceptions. For example, I thought that the scenario of a nuclear power station's control systems being accessible from the Internet was far-fetched, as I expected that it would operate on a completely isolated network for security reasons, but Google found at least one instance where this has actually happened ('Slammer worm crashed Ohio nuke plant network', Securityfocus.com).

It would be easy to dismiss this particular instance as a bad (and hopefully not very representative) example, but this would be missing the point. Even if nuclear power station control systems could/should operate in a completely isolated network, there are many other classes of systems that are part of the critical national infrastructure which will not have this option. These systems need to employ secure computing platforms and communication systems. 

This area is of particular interest to me, as this year I will be spending a significant proportion of my time focusing on Information Security (InfoSec). This is not just for Aerospace & Defence customers but also for security-critical applications in other vertical markets. Over the last two weeks, I've had the opportunity to get hands-on experience with VxWorks MILS, and I'm looking forward to gaining more experience in the coming year. I'm also getting up to speed with the Common Criteria, but I wish it was as riveting a read as the novel...

In-flight Internet access...and mobile phones too?

By Paul Parkinson

I read a business article in The Economist ('Mobile Phones on planes - Your call') during the Christmas holidays about the current developments in passenger in-flight systems, specifically the provision of Internet data access and the potential to support mobile (cell) phone voice calls during flight.

The article reports on trials of a Wi-Fi (Wikipedia) data service by JetBlue and Quantas, and a forthcoming mobile phone voice call trial by Air France (which follows on from the mobile phone SMS text messaging described in this Air France press release); it then goes on to discuss the social impact and acceptability of Internet data access and mobile voice calls during flight, which makes interesting reading.

The Internet, mobile phones and satellite communications have all been around for quite a while now, so you could be forgiven for wondering why we haven't seen these technologies rolled out across airline fleets before now? Well, maybe we are only just reaching the tipping point for technology (cost), and passenger demand (revenue)?

At present, the use of mobile phones in-flight is banned in the US by the Federal Communications Commission (and similarly by regulatory authorities in other countries) due to the potential for electromagnetic interference with aircraft avionics. If you perform a Google search, you might get the impression that this is a somewhat controversial subject with polarized views, but there is an example of hard experimental data to support the position on the UK Radiocommunications Agency website EMC Awareness page. There's also the problem that mobile phones passing over ground mobile networks at high speed could cause disruption as the networks struggle to perform handover from one cell to the next.

These new in-flight systems make use of a miniature base station on board the aircraft, known as a  picocell (Wikipedia), which connects to a satellite communications network to avoid both of these problems. This works because mobile phones transmit on increasing levels of power until they get a response - the concept is that if they receive a response from a nearby picocell they continue to transmit on low power levels, which will not interfere with aircraft avionics or reach ground-based networks thousands of feet below.

Despite this technological advance, I have to admit that I would try to avoid being on a flight where mobile voice calls were possible. This has nothing to do with the safety aspect, but because of the disruption. People tend to talk more loudly on mobile phones than on land lines because the sidetone on mobile phones is less than on landlines (sidetone is where the speech from the microphone is redirected to the speaker at a lower level, so that the person can hear what they are saying). If you now factor in the noise from the air-conditioning and jet engines, you've got a recipe for loud background chatter. The Economist article doesn't mention if these systems will support in-coming voice calls, but I certainly wouldn't welcome the sound of ringing mobile phones either, especially on a transatlantic flight, especially when I am trying to get some sleep! Maybe the reason why the airlines are being cautious about the introduction of voice calling is because they are wary of adverse passenger reaction?

On a positive note, I would very much welcome in-flight Internet data access, as it enable me to catch up on my email backlog, especially on long transatlantic flights. As an aside, my view on this isn't affected by the news story 'FAA: Boeing's New 787 May Be Vulnerable to Hacker Attack ' (Wired.com) which was posted earlier this week and was rapidly seized upon and somewhat sensationalized by the wider media. The Wired article, includes mention of "multiple networks", "isolation" and "air gaps" (i.e. physical separation) but doesn't really explain the concept of aircraft networks, which would have provided some useful context.

Basically, aircraft have a number of different type of networks, or domains, which connect systems which perform different functions; these typically include Flight Deck, OEM, and Passenger Systems. The networks have different networking requirements and are separated by firewalls for safety and security reasons (see ARINC 664 for more details) - one aircraft design already in-service is reputed to use a hardware diode to only allow the flow of data in one direction only between networks. In any case,  so I don't think this story should be a cause for concern for 787 passengers. Back to in-flight Internet access, I wonder if other laptop users would be trying to use Skype to make Voice-Over-IP (VOIP) calls? If so, I hope they don't sit near me.

So Is it finally time for take-off for in-flight Internet access?

Drive by Ethernet?

By Paul Parkinson

I read last week that BMW has been researching the use of the Internet Protocol (IP) over standard Ethernet (Cisco) to network automotive controllers ('BMW brings Internet protocol under the hood', EETimes).

The motivation for the research is that at present, a number of different networking technologies (including CAN, LIN, MOST and FlexRay) are used in automotive applications, and these are optimized for different types of application, but the lack of standardization results in complexity and cost.

So, I was expecting the article to say that BMW had found Ethernet to be suitable for non-critical applications, but not well-suited to critical systems. Sure enough, the article mentioned that the network had included a multimedia server and a camera (presumably for assisting reversing rather than videophone calls), but I was surprised that the BMW research group had found that:

'IP could well suit the real-time requirements even of safety-critical applications...Our experiments with prototypes demonstrated, that the real-time behaviour far exceeded the requirements — even when we ran multimedia applications across the same network'

Why was I surprised? Well, Ethernet, following its invention at Xerox PARC in the early '70s has become extremely widely used due to an ongoing favourable performance to price ratio, but it does suffer from latency and determinism problems to a certain extent, and while this has been acceptable for many uses including even some A&D mission-critical systems, safety-critical systems which require predictable latency and guaranteed delivery have often used profiled Ethernet implementations (such as ARINC 664) instead, sometimes with the additional expense of AFDX dual-redundant networking.

So, the BMW research engineers must have found away around the automotive problem? According to the article, they used Quality of Service (QOS) and traffic-shaping (wikipedia) techniques to achieve the real-time performance requirement, but unfortunately it doesn't go into details. I'm curious to know if the network profiling requirements for automotive applications have any similarities with avionics networks, or if there are major differences in terms of latencies and traffic characteristics. Maybe there's scope for more technology transfer between the two sectors (as I mentioned in my previous blog)?

There is potentially another interesting parallel between automotive and A&D - the use of multiple networks. In aircraft, multiple on-board networks are used for avionics systems, crew information systems and passenger infotainment systems, separated by firewalls for reasons of safety and security. (This also has the added benefit of reducing the safety certification burden of systems because they are not connected to the avionics network). In a car, I would expect that the automotive control systems would be on a separate network from the infotainment systems (for safety and security reasons).

According to the EETimes article, BMW doesn't have any current plans to put this technology into a production model yet, new technologies often appear in manufacturer's new high-end models, and then the technologies tend to trickle down to other model ranges.

So, unfortunately I might have to wait a while to do a back-to-back test of Ethernet-driven and conventional versions of BMW's awesome new V8-powered M3 to compare the latencies of the Dynamic Stability Control (DSC)...

Military Aerospace & Electronics Show

By Paul Parkinson

Yesterday, I attended the UK's Military Aerospace & Electronics technical conference and exhibition, which was held at the Heritage Motor Centre. The technical conference was split into three technical tracks, which were broadly related to avionics, land systems and technologies; and as is sometimes the case at these conferences I found that I wanted to attend some presentations which were running concurrently!

At a high-level, there were recurring themes amongst the presentations relating to modularisation, reconfigurability and of course, security. Some of the presentations discussed these issues in the context of the Future Rapid Effects System (FRES) programme, which is broadly speaking the UK equivalent of the US Future Combat System (FCS) programme. It was interesting to hear how future upgradeability through planned obsolescence and technology insertion prior to deployment, and the recognition that standards-based open architectures could facilitate this requirement.

Michael Morua of Atkins Defence Systems (MOD-appointed Systems House for FRES) gave a technical presentation on how the FRES Electronic Architecture (EA) is being implemented using a service oriented architecture, and even explained how reconfigurability would be achieved through open interface standards, and interfaces to external systems could be implemented through common data exchange middleware.

I always appreciate the opportunity to learn about emerging technologies at these conferences, so I was glad that I attended Peter Allsopp of GE Aviation's (formerly Smiths Aerospace) technical presentation 'Networked Aerospace Systems - Future Data Network Technologies'. It was interesting to hear how as data throughput requirements for avionics networks increase, the determinism, latency and availability requirements become harder to maintain with current avionics networking technologies. It appears that FlexRay, an open standard for time-triggered field bus technology may provide the way forward.

FlexRay was originally developed for safety-critical automotive applications, so it's encouraging to see that avionics can potentially benefit from the more widespread deployment of technologies in the automotive sector. This suggests that there can be cross-fertilisation between aerospace and automotive in both directions (blog: Can Automotive learn from Avionics Safety?).