Paul Parkinson

IDEF 2011

Last week, I attended the IDEF 2011 defence trade show in Instanbul as part of the Wind River team exhibiting on the Tektronik (Turkish distributor) stand.

Our partner, Curtiss-Wright, who were also exhibiting at the event, had kindly lent me a VPX chassis and VPX6-185 board, which I used to demonstrate a Cross-Domain Solution (CDS) demo running on VxWorks MILS. The demo filters packets of data between black and red 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 decided to replace it with a stronger encryption algorithm which is more appropriate for real world systems. I initially considered using an open source implementation of AES-256, but then I remembered the export controls on 256-bit AES, so I decided to use a public domain implementation of the Russian GOST 28147-89 (which also uses a 256-bit keys).

I managed to get the GOST encrypt and decrypt routines running fine natively under Windows, and also on the VxWorks Simulator running on the Windows host, but I could not get the GOST decrypt routine to work correctly on the PowerPC target board. It turns out that the GOST algorithm assumes that it's running on a little-endian processor! So, I had to stick with the simple encryption algorithm for the time being, and will have to wait until the Cross-Domain demo is running on VxWorks MILS on Intel architecture before I can use GOST.

Finally, some of my colleagues have been blogging about Wind River's 30th anniversary recently, and some of the things that they have got up to at Wind River. As I've spent my time at Wind working in the Aerospace & Defence sector, there are plenty of cool projects which I've worked on over the years which I can't discuss, but there a some highlights which can mention. For example, it's not every day you get the opportunity to sit in the cockpit of an F-16!

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.