Building a Flexible Security Architecture for VoIP Applications

By TMCnet Special Guest

Rick Pitz, Senior Product Manager, Certicom, Inc.

 

Voice over IP (VoIP) has evolved rapidly over the past few years. Security in a VoIP system has often been an afterthought, with several competing technologies emerging in deployed systems and products. VoIP security is a multi-layered effort, with requirements varying greatly from application to application. This creates a significant challenge for product planners and developers, who must balance the need for strong security with cost pressures and performance objectives. 

 

Some applications may need only basic authentication, while others may need to protect the signaling channel, the media stream, perform secure boot, etc. Developers of VoIP phones are further challenged by the selection of security protocols. One carrier may support the use of IPSec for securing signaling, while another may support TLS, requiring the developer to create multiple versions of a product, or a single product with multiple protocols.

 

If the same product or family of products will be sold in different applications, the selection of the proper security architecture can significantly reduce the time required to design and integrate multiple layers of security.

 

Well-designed security architectures, therefore, can be defined as those having one or more sets of cryptographic functions and security services capable of accessing cryptographic functions via a common application programming interface (API), as shown in the image below.

 

 

Cryptographic functions can be provided as a set of software libraries or, for performance reasons, may be provided in hardware. 

 

The security API is the interface through which applications use the services provided via a cryptographic provider. Each cryptographic provider has a corresponding adapter. The adapter is the link between the security API and the cryptographic provider. 

 

The adapter is also a software library that contains one or more registration functions for each cryptographic feature from a cryptographic provider. When applications wish to make use of cryptographic functions they make calls into the security API, which in turn maps those calls to the appropriate cryptographic provider.

 

Hardware cryptographic providers require the use of a board support package (BSP) which maps the specific hardware capabilities to the security API in much the same way as the software adapter maps the software based crypto to the security API.

 

Since the crypto algorithms required may vary greatly based on application, it is not uncommon to see a solution that includes hardware based crypto and software based crypto since the hardware solutions generally support a limited set of crypto functions. 

 

For higher levels of security, especially in government applications, a FIPS 140-2 certified crypto library supporting the NSA Suite B algorithms may be required.  Additionally, user and device authentication may require the use of additional hardware devices such as smart cards. 

 

The security services, such as IPSec and TLS, may need to access crypto functions that exist in one or more of the underlying crypto implementations. Since the security API abstracts the crypto implementation from the services and applications, the developer can easily change the underlying crypto implementation based on market changes, technology advances, etc., without the need to make changes to the services and applications that use the crypto. 

 

This also allows the same upper layer application and service code to be deployed in a family of products, where a low end device may use software crypto only, and a higher end device may use hardware based crypto for improved performance. The service need not be aware of how the crypto is implemented.

 

The security architecture should allow the developer to include or exclude any number of services or crypto algorithms. Certain products may have limited memory space, and as such, the developer should be able to take a crypto library and include in the executable file only those algorithms needed for the target application.

 

Similarly, the developer should be able to include only those services needed.  Where a family of products is being developed, this can greatly reduce the development time, as differences can be handled at build time through the use of different makefiles, eliminating the need for different source code files for each product variation.

 

Other applications in the VoIP device, such as secure boot, may need to access the crypto functions directly, without using one of the security services. The security architecture should expose the necessary API to the application layer to enable other applications in the product to use the same underlying crypto algorithms. This eliminates the not so uncommon practice of including multiple versions of the same cryptographic algorithm, reducing code size and maintenance complexity.

 

Due to the nature of the developing VoIP market, it is expected that devices will need to be updated on a periodic basis, to update features, fix bugs, patch security vulnerabilities, or to take advantage of newer protocols and standards.  A well-designed product will allow these updates to take place remotely, while ensuring the validity and security of the update. 

 

The product developer can ensure that the updated code is received securely by employing standard code signing techniques, which utilize the same cryptographic functions as previously discussed for authentication, integrity and privacy.

 

Products that use digital certificates and/or security keys must protect those certificates and keys.  The security architecture should support standard embedded trust system functionality to provide for secure key storage and should have the ability to incorporate PKI functionality for digital certificate processing and storage.

 

In summary, the security architecture employed in a VoIP device needs to support layered security to secure both the signaling and media channels. It must be flexible to allow different cryptographic providers to be used transparently to the services and applications that need crypto functionality. It must be able to protect the keying and certificate material, and must allow for secure updates of the firmware in deployed products. 

 

By employing such an architecture, the developer will greatly reduce development effort and complexity, while gaining the flexibility to extend, modify and customize product implementations to address dynamic market conditions.