To date, much security work for software defined radio (SDR) focuses on traditional communications security issues, particularly the confidentiality of voice and data transmissions. So when people hear “security,” they think about data encryption, key management and the separation of classified and unclassified data. However, SDR security involves a broader range of issues, many under the rubric of software assurance. In short, radio users need to have confidence that radio software will perform as advertised—to know that the code was developed using reliable software development methods, was thoroughly tested by someone they trust and wasn’t changed after the testing was completed.

Radio Software Assurance

Ultimately, software assurance may be more important to many radio users than traditional communications security. In today’s world, the risk that an adversary will expend resources to crack the cryptography protecting real-time or tactical wireless communications is small relative to other threats. Conversely, the risk that bad code could cause a radio to malfunction or cause interference with other legitimate radio communications is very real. In a worst-case scenario, bad code may have worm-like replicating behavior, impacting the radio communications of an entire organization or community of users. In the absence of appropriate controls, adversaries interested in compromising communications security may find that replacing SDR code on a radio platform is much easier than cracking its cryptosystem. To explain the difference between communications security and software assurance, Table 1 lists potential attacks on both.

Assurance is significantly more difficult for SDR than it is for traditional hardware-based radios. Once a hardware radio design has been certified to meet functional and security requirements, users can be confident that radios off the production line will meet the requirements through the radio’s lifetime. Tampering with radios is possible, but it can only be done to one radio at a time. The adversary must have physical contact with the radio and technical expertise.

SDR changes the threat. Software updates can modify multiple radios simultaneously. Physical contact is not necessary because malicious code can be inserted during the development process or during remote software downloads. User-friendly software tools may allow adversaries to modify radio code and its behavior with relatively little expertise.

Software Certification

Software certification can provide required levels of assurance. Comprehensive SDR certification could ensure that adversaries cannot circumvent security controls. It should include examination of the SDR device boot procedure and mechanisms to achieve process separation and memory isolation. Table 2 lists potential controls and countermeasures that should be tested during certification.

SDR certification is largely in its infancy. The National Security Agency (NSA) provides the most comprehensive program—security testing of SDR technology developed for the Joint Tactical Radio System (JTRS). But details of the program are classified, which limits the scope to the U.S. DoD, effectively precluding other SDR users, including U.S. allies, from leveraging it.

The Federal Communications Commission (FCC) also has an SDR certification program, but it has no defined methodology, preferring a case-by-case approach at this stage in the evolution of SDR technology. Only one company—Vanu—has successfully navigated the process to obtain a license. The good news is that most FCC proceedings are public, which means others will benefit from advances made in this area. The not-so-good news is that FCC’s interests are narrowly focused on illegal radio interference, which is only one aspect of the range of SDR security issues to be addressed. Typically, FCC activities are not applicable to military or non-U.S. communications.

For the commercial aviation industry, the U.S. Federal Aviation Administration’s Advisory Circular 20-115B establishes Radio Technical Commission for Aeronautics (RTCA) DO-178-B guidelines as a de facto assurance standard for software development. But these guidelines do not specifically address radio software or security considerations, focusing instead on development practices and documentation.

The SDR Forum has plans to develop protection profiles that could be used in certifications of SDR implementations under the Common Criteria. Common Criteria certification has a number of valuable characteristics—certifications are internationally accepted and the process is widely viewed as rigorous. However, the certification process is lengthy (several months to a year) and expensive (typically over $250,000)—perhaps prohibitively so for an emerging technology experiencing rapid change. In addition, the SDR Forum is unlikely to complete its protection profile work before 2008, meaning that Common Criteria certification is a medium-term solution at best.

Software testing and certification is a critical component of software assurance. SDR users should be advocates for its continued progress, but maturity is still years away. In the interim, both the developers and consumers of SDR technology need to build internal controls to ensure that SDR technology risks are mitigated.

Code-Signing Radio Software

An important tool in software assurance is the application of digital signatures to software objects. A digital signature on radio code binds the identity of the signatory to a specific instance of the code. This action has several important characteristics. First, it provides a high degree of integrity assurance—the software has not changed since it was signed. Second, it provides non-repudiation—a signatory cannot later deny signing the object. These properties of digital signatures derive from features of asymmetric or public key cryptography and therefore will be accompanied by a public key infrastructure (PKI).

Signed code is not necessarily good code. The signature may signify nothing more than that a particular entity is choosing to associate with the code—most likely a developer meeting a security requirement to sign its product. However, other organizations might only sign code if it first passes a rigorous series of tests. Indeed, the assurance that the signature provides depends more on what operational practices are required to obtain the signature than on the signature’s cryptographic strength.

Fortunately, the code-signing model provides user communities a path to enhance assurance over time. Near term, signatures can provide assurance of the code’s integrity and that it comes from a known source. Long term, signatures provide evidence of security certification. From the perspective of the radio platform, both levels of assurance can be obtained using the same cryptographic modules for digital signature verification, which could be relatively easily obtained today using widely available COTS software libraries and tools.

Security professionals are nearly unanimous that the code-signing approach is ideal for SDR. The SDR Forum, European End-to-end Reconfiguration (E2R) Project and university researchers all recommend a concept of operations based on digital signatures. Most also envision multiple signatures on software objects. For example, the radio platform manufacturer might sign executable code to signify its compatibility with its systems, an independent lab might sign to signify that certain security functionality is present, while a government agency might sign it to signify that it is suitable for a particular application. Multiple countries might sign software for international applications. The permutations are endless, but they need not be predetermined because digital signature mechanisms could be designed to support all of them.

Manufacturers and users are embracing the approach, albeit much more slowly than preferred. For example, the Security Supplement to the JTRS Software Communications Architecture (SCA) requires that SDR devices “shall only accept cryptographic algorithms/algorithm packages signed by NSA,” that “NSA shall digitally sign all Security Policy XML files,” and that “the [operating system] invocation method shall be a NSA digitally signed script.” However, SDR middleware and tools vendors supporting JTRS customers do not yet support digital signature features within their products, although they express openness to including such features in future releases. Similarly, user and manufacturer representatives in the SDR Forum’s Public Safety SIG are trying to identify alternatives to digital signatures before committing to such an approach, largely due to perceptions about PKI technology complexity.

The Trusted Network Approach

One alternative to digital signatures is to distribute radio software over a trusted network. The idea is that if strong authentication is required to attach to the network and the data that traverses the network is encrypted, this provides assurance that the code comes only from known sources and is not modified during distribution. The FCC rules on SDR explicitly allow such an approach, which Vanu implemented for its Anywave Base Station. Military and commercial aviation sources suggest that secure networks, combined with well-defined operational practices, may adequately protect the radio software integrity during distribution.

Unfortunately, the trusted network approach is at best an interim solution restricted to highly vertical integrated SDR service providers—organizations that have control over everything from development of the software to its operation in the field. Vanu is such an organization because it both builds and operates its SDR solution, but in the future its ambitions may push it beyond this limiting model. Military SDR communications can also fit into this model if its personnel and various contractors are perceived as a single unit, but the resemblance breaks down as the number of vendors proliferates and with requirements for joint operations and radio communication with allies.

The core problem of the trusted network approach is that it assumes that radio code can be limited to such a network. In the real world, this restriction poses a significant burden on all parties that need to touch the software at some point in its life cycle—developers, auditors, certifiers, network operators and users. The model fails to provide non-repudiation for specific instances of code and does not work well with Mobile Ad-hoc Networks (MANETs), whose infrastructure cannot be predetermined by definition. The code-signing approach, on the other hand, preserves the integrity of code and certification bindings even when the software is retrieved off an enemy’s server, a characteristic that enables enormous

flexibility in its distribution. The only requirement is that each signatory maintains the secrecy of its private key, which should never be shared with another entity in any case. Figure 1 illustrates relationships between various entities in the code-signing and trusted network paradigms.

The Dilemma of Software Patches

An important value proposition of SDR is reconfigurability. While hardware radio retrofits are rare, software radios expect to receive periodic upgrades. Ideally, the updates will be to enhance functionality or performance, but some updates will be required to correct an error or security vulnerability discovered after the software is installed.

Software patches are problematic. On the one hand, assurance requirements dictate full testing of the patch followed by appropriate digital signatures. On the other hand, operational requirements dictate that patches be applied quickly to avoid mission failure, a security breach, revenue loss or some other adverse consequence. A significant risk exists that the patch could cause more damage or introduce a greater vulnerability than the code it replaces—that the cure might be worse than the disease—which is made all the more probable when patches are written hastily in a crisis environment.

In most environments, assurance requirements are subordinate to immediate operational needs. Adversaries will try to exploit this situation if they know that security controls are significantly reduced or even ignored for patches. Designing for high-assurance SDR environments requires procedures and mechanisms that resolve the tension between responding in a timely manner and preserving the integrity of information assurance processes. The best way is to develop expedited testing processes for emergency patches and include an expiration date in signed patches that effectively forces entry into the complete assurance process after the emergency has passed.

The Future of SDR Security

The long-term vision for SDR includes modular, reusable and portable software components. Realizing this vision enables exciting new business models in which companies can focus on aspects of radio functionality, rather than integration of entire communications devices. The SDR industry may begin to look like the early personal computer industry, with similar levels of growth and technical innovation. Yet in the vision is also the fear that radios will inherit the problems of PCs, including their unreliability and their vulnerability to malicious code. Fortunately, this time around we are much better prepared. Today, digital signature technology coupled with high-assurance COTS operating systems can enforce a wide range of SDR security requirements. The future of SDR security depends largely on whether SDR vendors and customers will choose to use them.

Bernie Eydt is chairman of the SDR Forum’s SDR Security Working Group.

Booz Allen Hamilton
McLean, VA.
(703) 902-5000.
[www.bah.com].

Radio Technical Commission
for Aeronautics
Washington, DC.
(202) 833-9339.
[www.rtca.org].

SDR Forum
Denver, CO.
(303) 628-5461.
[www.sdrforum.org].

Vanu
Cambridge, MA.
(617) 864-1711.
[www.vanu.com].