Paul Parkinson

The Open Group: Real-Time Embedded Systems Forum, Rome

Last week, I attended the The Open Group, Rome 2010 conference, specifically the Real-Time Embedded Systems Forum track (agenda), in order to participate in the MILS API standardization working group sessions.

The goal of the working group is to produce a standardized API for a Minimal Runtime (MRT) environment which is suitable for High Assurance systems, which will enable portability of middleware between MILS platforms and aid interoperability. The working group wrestled with some fundamental aspects of the MRT, including goals/objectives, characteristics and implementation architecture, but these were productive sessions. There's still a long way to go, but these were important steps in the right direction. Watch this space for further developments!

It was also useful to have the opportunity to attend the RTES Forum presentations. Some of the highlights for me were Ed Roberts of Elparazim's presentations on AADL, Olaf Tetteo of Brightsight's presentation on 'Certification & Mutual Recognition above EAL-4 in Europe', and my colleague Alex Wilson's presentation on 'Challenges of Multicore, potential impact on Safety Critical and High Assurance Security Environments'. Open Group members can download the proceedings from here (login required).

With such a packed agenda, I was worried that we might not have an opportunity to see the delights of Rome, but fortunately for the Tuesday evening, The Open Group had arranged a tour of the stunning Capitoline Museum followed by the conference dinner on the rooftop terrace which had a spectacular view of the city skyline.

A Decade at Wind River

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.

A&D Regional Conferences

I've recently finished updating presentations on The Essentials of Multicore Software and Challenges of Security Software Development for our forthcoming Aerospace & Defence Conferences which we are holding across Europe in November.

It's been interesting to think about how multicore can be used in technology refreshes and applied to new programmes. I'm looking forward to discussing these issues with customers, as well as understanding their security requirements, particularly as the need for interoperability continues to grow. We also recently demonstrated some of the capabilities to meet these security requirements in a cross-domain system and Gigabit Ethernet demo running on VxWorks MILS at MILCOM in the US, and the videos are available on YouTube.

If you've not received an invitation to one of the European conferences yet or had a chance to register, why not visit our conference portal? I hope to see you there.

VxWorks MILS 2.0 at DSEi 2009

I am looking forward to Defence Systems and Equipment International (DSEi), the world's largest fully integrated international defence exhibition, which is being held in London from 8-11th September 2009. In preparation for the event, I've been setting up some Wind River VxWorks MILS 2.0 demos on a Curtiss-Wright VPX6-185 board.

VxWorks MILS is Wind River's implementation of the Multiple Independent Levels of Security (MILS) security architecture, which can host applications running at different security classifications, including multilevel secure (MLS), on the same platform. VxWorks MILS is able to do this by implementing information flow control, data isolation, periods processing and damage limitation, whilst ensuring that data does not leak from one partition to another through either overt or covert channels. The demos also show how Wind River Workbench can perform concurrent debugging of multiple partitions, which is invaluable when developing multi-partition systems.

I've also been working on some modifications to a Wind River VxWorks MILS demo which is representative of a real-world application, a Cross Domain Solution (CDS). This filters packets of data between different networks based on the security classification of the data, and uses multiple partitions to implement sender and receiver on different interfaces.

The demo currently uses a simple encryption algorithm for data passed over the black network (which wouldn't present much of a challenge to GCHQ/CESG or NSA). So I am intending to replace this with a stronger encryption algorithm which is more appropriate to the application.

However, I've been presented with a challenge as most of the encryption algorithms in the public domain are available as C language source code, but my colleague has implemented the black host application in Java. Ironically, after some thought, I decided (as a C programmer) it would be easier for me to port the host Java application to C rather than to port the encryption algorithm to Java.

Now, as I've done that, I just need to decide which encryption algorithm to use. I have the C source code for the encrypt algorithm for the German Enigma cipher machine (which I have seen working), but unfortunately not the decrypt algorithm. However, I have also found a nice crypto algorithm with encrypt and decrypt routines in C, but when I looked through the source code I noticed that it assumed that it was running on a little-endian processor, and I want to run the encrypt on little-endian and decrypt on big-endian, so it looks like I have some more work to do!

Anyway, if you would like to see the VxWorks MILS demo running and discuss how it works, or would like to discuss your security requirements, you'll be able to find me on the Curtiss-Wright stand (724). See you there!

VxWorks MILS 2.0 EAL6+ Evaluation

In case you missed the news, VxWorks MILS 2.0 has officially entered formal security evaluation at Common Criteria EAL 6+ (NIAP website).

So what does this mean for Wind River's customers? Well, VxWorks MILS 2.0 will enable them to develop applications to what the US National Security Agency (NSA) defines as "High Robustness".

Many people are familiar with Communications Security (ComSec), which involves the secure transmission and reception of information across networks, using technologies such as encryption and firewalls. However, what is less well known is Information Security (InfoSec), which involves the secure transformation of information between applications, subsystems, or networks. This is becoming an increasingly important requirement in systems, where there is the need for applications to handle data of different security classifications and to ensure that only that the authorized data flows are allowed and no unauthorized information disclosure can occur.

In the defence sector, the application of VxWorks MILS 2.0's high robustness technology is obvious, providing the means to host Top Secret (TS), Secret (S) and even Unclassified (U) on the same platform. This could be used for example in a military UAV mission system which needs to communicate with a civilian Air Traffic Control (ATC) system as it flies through unsegregated airspace (my colleague Chris Constantinides & I discussed this scenario in detail in the case of a UAV system architecture in the paper "Security Challenges in UAV System Development", at the 27th Digital Avionics Systems Conference, IEEE Proceedings).

In the commercial sector, VxWorks MILS 2.0's high robustness could be used to protect critical national infrastructure, which is a growing concern given the increasing threat of cyber warfare - see my previous post 'Cyber warfare and déjà vu' and the recent news story 'Electricity Grid in U.S. Penetrated By Spies' (Wall Street Journal) for details. This technology could also provide a secure platform many other types of application that needs to enforce strict separation based on data classification and access controls, including banking and commerce, to name a few.

So, even if our customers are working projects which don't have an explicit InfoSec requirement today (perhaps because the systems aren't even networked), it is reassuring to know that they have a route to Common Criteria security certification with VxWorks MILS 2.0.

Now, I must get back to learning a crypto demo which one of my colleagues has created for VxWorks MILS 2.0...

Cyber warfare and déjà vu

Yesterday, I had strong sense of déjà vu as I read the news story 'Major cyber spy network uncovered' (BBC News), which reports on a 10-month investigation by the Information Warfare Monitor (IWM) into a cyber espionage network, which they called GhostNet. This has a number of similarities with the plot within the novel 'The Edge of Madness' which I discussed in a previous blog.

The IWM report ''Tracking Ghostnet: Investigating a Cyber Espionage Network' is comprehensive to say the least, and I expect that people will find it either fascinating or terrifying, depending on their disposition. The IWM report is available to view online at the IWM website, but I found it more convenient to download the PDF version from the F-Secure mirror site to read offline.

The report contains lots of fascinating detail about the IWM investigation, but what really struck me was that the infection methods (p 39) were all based on contamination of data with executable code (web pages, PDF documents and Word documents), and relied on the application processing the data to execute the code. Once these trojans had opened a back door into a system, this provided access to the attacker for control and further exploitation.

This security vulnerability is due to the principle of allowing applications to run commands and/or code from an external source.

Q. Do I trust my web browser not to run malicious code?
Well no, I don't. I could disable all Javascript and Flash in my web browser and restrict other behaviour as well, but that would mean that many websites would become unusable.

Q. Do I rely on the host operating system to limit their actions?
Again, no, as the host operating system that I have to use has a relatively weak file system and security architecture.

So, because I don't trust either the web browser or the host operating system on which it executes, I instead use an secure containment approach. I do this by running the web browser in a virtualized environment. This means that the web browser has only the resources it needs to operate, but runs in a restricted environment, isolated from the rest of the system and is unable to perform priviledged operations, and most importantly it cannot access or corrupt my documents.

I decided to use this approach a while ago, after learning about the secure separation kernel and virtualization approaches used in VxWorks MILS 2.0, and after reading the IWM report my actions no longer seem as paranoid to me as they did at the time...

Quantum Leap for encryption

The topic of data security is finding its way into mainstream media news reports these days, often due to high-profile lapses or breaches; and whilst encryption is sometimes mentioned in passing, the media reports rarely delve into the detail.

So, on Wednesday evening when I had the opportunity to attend a local history talk about the Enigma machine and other encryption devices, I jumped at the chance. In addition to listening to the talk, I saw a number of working exhibits, including two Enigma machines used during WWII, and a Russian Fialka which was used in the Cold War.

One of the things which struck me about the talk was the race to increase encryption strength versus code-breaking attacks, and how these related to the computing power available at the time. In the early 1940's, the British used Colossus, the world's first programmable digital electronic computing devices to break the Lorenz cipher, used for German high-level military communications. Colossus was able to decipher an encrypted message in hours, far faster than by other means available at the time; whereas today a Lorenz simulator can be run on a modern PC and break an encrypted message in minutes.

The widespread availability of high-performance PCs available now at relatively low-cost, and modern encryption technologies, such as TrueCrypt and PGP, means that data can be secure from prying eyes, apart perhaps from those with arrays of supercomputers at their disposal.

However, the advent of quantum cryptography ('Quantum Leaps', IET Engineering & Technology) could result put an end to this race in the near future, by finally providing unbreakable encryption and intercept detection. If realised, this would render brute-force computational attacks to be useless, and attackers would be forced to revert to compromising the encryption keys instead....which is another approach which has been used for years, so maybe the status quo will remain?

Security and cyber warfare

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...

Mobile phones clear for take-off?

A few months ago I commented on some of the technical developments in passenger in-flight systems ('In-flight Internet access...and mobile phones too?'). In recent weeks, there have been some rapid developments, not on the technical front, but in terms of regulation and operation, with announcements from the UK telecommunications regulator Ofcom and the European Commission.

On the 26th March, Ofcom published the results of its consultation on the use of Mobile Communications on Aircraft (MCA). The executive summary summarizes the findings and Ofcom's decisions, but the full statement (PDF) provides much more detail, revealing a mixture of social, operational, safety and security issues.

The social issues which revolve around the acceptability of using a mobile phone in-flight, seem to have been brushed aside in the following statement:

3.9 Ofcom also understands the concerns expressed about peace and quiet on aircraft and the potential for mobile phone users to annoy other passengers. However we note that in similar cases which can lead to annoying behaviour, for example serving alcohol on board aircraft, it is a matter for aircraft operators to decide how to balance the services they offer to their passengers with the impact that they have. The airline industry is a competitive market and consumers generally have a choice between carriers: the provision of MCA services, and approaches to mitigating any annoyance, like quiet zones or quiet periods, could become part of the marketing differentiation between airlines. Further, Ofcom considers that UK consumers could be disadvantaged if MCA services were not permitted.

The comparison between serving alcohol and mobile phone use is unconvincing, because a passenger sitting in the next row having a drink is not likely to affect me unless they are drunk and unruly, whereas a passenger whose mobile phone and then talks loudly (to be heard over the background noise of the aircraft) will affect (i.e. annoy) me - I suspect a comparison between smoking in-flight and using mobile phones in-flight would have been more appropriate! For a more considered view on the social issues, I'd recommend Clive James' eloquent article 'I'm on the plane... the PLANE' (BBC Magazine).

The operational and safety issues are inter-related in some cases. For example, the proposed use of mobile devices is intended for use only above 3,000m altitude, and should be switched off during take-off and landing. However, once passengers become aware that mobile phones can be used at all on some flights, they are likely to become even more cavalier than they are at present (for example, on a recent return flight from San Francisco, a lady sitting across the aisle from me was using her BlackBerry  crackberry for email and phone calls while the plane was taxiing and only switched it off just before takeoff). Passengers probably won't distinguish between aircraft that have pico cells for mobile phone calls, and those that don't - the latter resulting in the mobile phone transmitting on increasing power levels in an attempt to connect to a base station, and thus increasing the risk of electromagnetic interference with aircraft electronics. These issues still need to addressed to the satisfaction to the UK CAA and EASA before mobile phones can be used in-flight over the UK and the rest of Europe respectively.

Some of the individual responses in the Ofcom consultation raised a number of security issues, however the Ofcom response was that this is responsibility of the DfT's Transport Security Branch but I couldn't find a responses or policy on mobile phone in-flight use on the Department for Transport's website.  The situation seems somewhat different in the US, where the Department of Homeland Security is openly opposed to the use of mobile phones in flight on security grounds ('Why US Airlines Still  Won't Join the Mobile Mile High Club').

The European Commission announcement (BBC News) makes it clear that the regulations not only allow for mobile data and text messaging services (which has been the focus of the recent trials by Airbus and Quantas), but also for both incoming and outgoing voice calls. Whilst the mobile network operators and airlines seems to be falling over themselves to introduce this technology, I can't help wondering whether this is what passengers actually want? It looks like I'm going to need to carry extra batteries for my Bose noise canceling headphones...

Linux fit for Defense

In an earlier blog, I commented on the potential use of Linux in Aerospace & Defense, but I didn't provide any background information to support my assertion that people seem to either love or hate Linux, and that often their views are formed from emotive arguments and prejudice rather than rational fact-based discussions.

Last week, Paul Tingey discussed some interesting examples of polarised views in different countries in a recent blog Open Source: Do you love or hate it? So, I thought I should comment on some of the views which have been expressed in relation to the use of Linux in defence.

In the article 'No Defense for Linux' (Design News), Green Hills Software CEO, Dan O'Dowd, shared his views into what he believes are potential security issues relating to the use of Linux in defence systems. The article is both interesting and thought provoking, and Mr. O'Dowd raises some important questions which do need to be considered.

A number of other bloggers have already commented on this article from a number of angles, the one's which I found the most interesting were Victor Yodaiken: Green Hills, foreigners and the gummi bear threat'; Dana Blankenhorn: 'Is Linux a Danger to National Security?', and  Perry E. Metzger: 'News Flash: Proprietary OS vendor dislikes Linux!'). However, I want to follow-up on two of the arguments in the article in particular, as they do not appear to stand up to close scrutiny:

1. Open Source peer review
   Mr O'Dowd asserted that "many eyes" are no defence against subversive or malicious code which could be used to undermine system security.  However, this argument is inconsistent with the accepted best practice for the definition of network security protocols. It has been well documented that security protocols, such as Wireless Equivalent Privacy (WEP), which was designed in isolation without peer review by security experts, was fundamentally flawed. The flaws are documented in Security of the WEP algorithm (Berkeley), and the lack of peer review is highlighted by Jon Edney and William Arbaugh in their book "Real 802.11 Security". This should be contrasted with the approach taken to develop 802.11 wireless security which uses the Advanced Encryption Standard (AES, wikipedia).
   
2. Vulnerabilities in Binary Code
   Mr. O'Dowd also asserted that 'source code inspection will never detect vulnerabilities that are only manifest in a system’s executable binary code', which is of course a valid statement. However, the example which he used to illustrate this doesn't actually support this argument. He cited the story of Ken Thompson, one of the original designers of the UNIX operating system, who installed a backdoor (a.k.a. Trojan Horse - wikipedia). Mr. O'Dowd said that Thompson "installed a back door in the binary code of Unix". This statement seem to be slightly ambiguous to me, and I wasn't sure if it meant that the backdoor was installed into the UNIX kernel, so I checked the original article by Ken Thompson 'Reflections on Trust ' (ACM) and found that states explicitly that the Trojan code was actually contained within the UNIX C compiler:
   

   "The actual bug I planted in the compiler would match code in the UNIX "login" command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user."

   So, the comparison between Linux and UNIX  does not appear to be valid in this instance because the GNU C compiler used in Linux is Open Source whereas the UNIX C compiler was not. So the Linux GNU C compiler can undergo source code inspection in the same way as the Linux kernel, so there will be no binary code that has not undergone source code review. Ken Thompson also described a very devious approach to install a backdoor into the UNIX C compiler, which would re-insert itself without when the compiler was recompiled. However, Ken Thompson acknowledged in his article that:
   

   "Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions."

   A backdoor could be inserted into the GNU C compiler using the same technique, but this could be detected by disassembly of the compiler.

So, it would seem that at least some of the arguments against the use of Linux in defence systems do not seem to have a firm foundation based on facts. Don't get me wrong, I'm not saying that Linux is suitable for all types of defence application, but as I discussed previously, I do think we need to have an open mind.