Advertisement
Product Releases
Advertisement

Trusted Platforms for Wireless Devices

Thu, 06/30/2005 - 9:54am

LISTED UNDER:

Shifting functionality out of hardware into software offers significant benefits. In addition to reducing costs and conserving physical space, this process offers a plethora of new functional possibilities. By Tony Walters

Five years ago, it might have seemed a stretch to suggest that — within the near future — cell phones would be able to switch automatically between licensed and unlicensed radio bands, effortlessly keeping evolutionary pace with radio standards. Well, with today’s SDR, the "near future" is almost upon us.


The recent profusion — and combination — of advancements in semiconductor design, RF methodologies, signal-processing techniques, smart antennas, and CPU and FPGA computation engines has allowed development of SDR, a collection of hardware and software technologies that enable architectures for reconfigurable radio systems.


SDR offers something for everyone. For end users it promises continuous connectivity. For operators, it offers unprecedented flexibility in service delivery, along with cost savings with respect to infrastructure investments and radio-spectrum licensing fees. For manufacturers, SDR stands — among other things — poised to prolong device lifecycles by giving them the means to adapt to new requirements and to better leverage capital investments by allowing one physical device to communicate with multiple, different basestations.


The Security Challenge

Unfortunately, the growing availability of downloadable software also presents significant security concerns in the case of SDR and for wireless devices in general. It is conceivable that a software configurable device could be maliciously or accidentally loaded with a self-replicating virus or worm, which is designed to propagate throughout a network and bring it down.


Furthermore, the operating parameters of transceivers are tightly controlled through a "type-approval" process. If parameters such as RF spectrum access and transmission power could be modified, it would potentially create havoc in a country’s public and private wireless networks. This is unacceptable, as one can readily see when considering "first responder" services that need guaranteed reliability for public safety. Such issues expand the use of security technology from protection of communications traffic to protection of operational parameters and allocated use of transceivers. These requirements for security apply across all transceivers, from short wave amateur radios to fire and police radios and on to national protection, military and marine communications.


Due to such concerns, much attention is being paid to securing software downloads. This is important, but it addresses only part of the security challenge. While upper-layer protocols can be used to secure application data and transactions, they do so assuming that the boot process and critical information on a device are secure. However, presently, little is being done to address that security portal.


In the broader computing world, the idea of building-in security at the platform level is beginning to take hold. For wireless devices, in which resources are constrained, the standard PC approach simply won’t work. But the concept of establishing a trusted platform can be adapted to the wireless environment in a way that respects its unique constraints.


Principles of Trusted Platforms

If a SDR device is to be protected from misuse, it has to be able to securely store credentials and keys — the elements needed to authenticate the device itself and confirm the integrity of the code it’s running.


Ideally, these authentication and integrity-checking functions should be performed as part of the boot process — the point at which illegitimate software (i.e., malicious or corrupt software, such as firmware, that has been downloaded from an external source) can take control and compromise the system.


A first preventive step is to secure the download process, thereby reducing the likelihood of malicious software entering the system. Thus, secure downloads form an important part of the trusted platform. Devices should be able to check new software coming in and verify that it originates with a known, secure source, and that it has both an authentic certificate and a valid digital signature. The secure boot occurs in addition to this initial check every time the device powers on, reconfirming the integrity of the new software.


This requires only a tiny trusted platform if keys are protected using a device-specific key that is not externally accessible and that cannot be modified without proper credentials (key wrapping). This reduces the requirement for secure and authentic storage to a single key, minimizing the incursion into hardware.


The secure boot process works well in both open and RTOS environments, but it offers specific advantages for open devices. Many open devices have multiple modules, code images and configuration files that must be loaded separately. To create trust from the platform upward requires hardware and software authentication for each of these components, which in turn demands fairly complex boot logic. Software is required to access protected memory, to analyze firmware stored in flash memory with respect to code-signature locations and to determine the course of action if code fails the integrity check.


In a complex device that is not fully open, an Authentication Entity or Trust Agent can be developed to manage firmware verification and software updates. In an open application environment such as WinCE, Symbian or Linux, this agent may need to be part of the kernel, helping manage restricted access to kernel resources typically controlled by user privilege levels.


On that topic, access control can be provided through an access control list, storing and maintaining user privileges in an authentic manner on the device itself. This can be programmed into ROM or under the control of a device-specific key that is not externally accessible and that cannot be altered without proper credentials. If user privileges are centrally controlled — as with policies mandated by radio regulatory bodies — then authentication can also be provided using digital signatures.


Building a trusted platform is essentially an exercise in making sure that all the necessary links in the security chain are in place. That security chain extends upward to the software layer. The software is able to trust the operating system that trusts the boot code, which has been demonstrated to be secure.


Six Degrees of Authentication

Okay, well not quite six. But it is important to differentiate among authenticating software, authenticating devices and authenticating users themselves.


With respect to securing downloads, although a pure integrity check is sufficient for ensuring that device software has not been tampered with or changed in power-off mode, digital-signature authentication is preferable for devices that are required to verify new software or configuration parameters over the air. Because the downloaded software hasn’t been seen before by the device, its source must be validated. Using digital signatures based on public key cryptography make this possible.


ECDSA is a good fit for an SDR application because it is extremely efficient in terms of space and power consumption. The NSA has recommended ECDSA for all U.S. government use. Signature algorithms are typically paired with hashing algorithms, and the cryptographic strengths of each must be commensurate. For example, ECDSA signatures based on a 256-bit curve should be paired with the SHA-256 hashing algorithm to maintain the overall level of systems security.


Device authentication requires that a unique, irremovable and unchangeable identifier be installed in every device at time of manufacture. User- or application-specific cryptographic keys (in the form of an X.509 credential representing a public/private key-pair unique to the user) should be issued to the party responsible for the device. This identity information can then be used for authentication in conjunction with the factory-installed keys to authenticate a device and indicate a user’s willingness to take responsibility for that device.


Although a device identifier can be used to uniquely identify a unit of hardware, an exchange of cryptographic keys is necessary to identify a specific user for the purpose of enabling processes such as billing and service requests.


How Strong is the Crypto?

As a rule, the algorithms used to secure wireless devices should be the most advanced available, in keeping with the nature of the device itself and the level of security required. Security should balance complexity against the threat to the device or network. For example, threats to radio-emission characteristics require stronger protection than threats to voice coders.


Flexibility can be established by using parameterized security methods and families of algorithms (allowing for variable security levels without significant increases in code or hardware), and through negotiated security methods and a robust security policy framework.


One might worry that implementing adaptable cryptographic strength would require the computational unit to be able to handle flexible parameters, thus leading to cost increases. This, however, is mitigated if the cryptographic constructs used all come from a similar class of algorithms.


Elliptic-curve methods for authentication, certificate verification and key exchange alleviate some of the resource challenges in constrained devices because they impose lighter processing and power requirements and occupy a smaller footprint. In addition, these methods are recommended within the U.S. government for both classified and non-classified uses and are upgradeable to more rigorous security requirements over time.


Architectural Considerations

Practically speaking, to create a trusted device, developers will gain the greatest advantage from using a comprehensive, modular security platform that allows security embedded in software to leverage the trusted platform. An embedded trust services module can then be used for authorization, secure storage of certificates and keys, and to manage access to hardware security functions such as hardware key-ring and key-wrapping services. The API for this module, if it permits software emulation of hardware facilities, would allow application engineers to code to one interface and reuse that work as often as needed.


Building in hardware crypto acceleration and key management facilitates the establishment of a trusted hardware platform. Secure boot and cryptographic software support create a trusted runtime environment, on top of which can sit the cryptographic functions.


Too often, DRM functionality, SSL, IPSec and other protocols will all have their own crypto providers. This becomes inefficient and difficult to scale. From a design point of view, once the secure boot process has been built, its architecture should be reusable—applicable to code-signing, validation, key management and other functions at all levels. With the addition of a hardware abstraction layer, code can also become more portable, allowing developers to use the same code across different versions of chipsets to meet varying market requirements.


Looking Ahead

Building a trusted platform ensures device security at the most fundamental level. This is essential for service providers who want robust protection of digital rights, and for mobile network operators who want to be confident that their customers are downloading only valid software updates and firmware upgrades.


It is also crucial if new technologies like SDR are to take flight. The potential of SDR is significant, not just for consumers, but also for public-safety organizations and military operations. Downloading software-based waveforms to re-task devices based on network availability would allow emergency responders, for example, flexibility to act quickly in the public interest. But those downloads must be secure and authentic, or else millions of dollars and even human lives could be lost.


The FCC has indicated its support of SDR. Many speculate that platform-level trust will be required for devices to enter into widespread, regulated distribution and use. At present, for approved wireless devices, the FCC maintains an image of the board design and compares that image to the finished product to confirm its authenticity. With SDR, there’s no image to capture. From a regulatory perspective, establishing a secure platform that can be authenticated may be the only way to go.


Whatever the case, it seems clear that as security demands become more intense and more complex, platform trust will become a dominant design consideration for wireless devices.


About the Author

Tony Walters is director of solutions for Certicom Corp. With 30 years experience in IT, Walters is responsible for developing solutions for Certicom's customers and for commercial and technical ecosystem development. Prior to joining Certicom, he was national director of Internet and E-Commerce Solutions with LGS Group, a 2,000-employee IT consulting organization. Tony also co-founded and developed JTS Computer Systems Ltd., which delivered document imaging and workflow technology for the financial services industry. JTS was acquired after 18 years by SNS (now BCE Emergis).


Glossary of acronyms


API— Application Programming Interface

CPU— Central Processing Unit

DRM— Digital Rights Management ECDSA— Elliptic Curve Digital Signature Algorithm

FCC— Federal Communications Commission

FPGA— Field Programmable gate Array

IETF— Internet Engineering Task Force

IPSec— Internet Protocol Security

IT— Information Technology

ITU— International Telecommunications Union

NSA— National Security Agency

ROM— Read-Only Memory

RTOS— Real-Time Operating System

SDR— Software-Defined Radio

SHA-256— Secure Hashing Algorithm, 256 bits SSL— Secure Sockets Layer

WinCE— Windows Compact Edition

X.509— a standard for public-key infrastructure


Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading