Real world examples of the ideas covered in the first part of this article abound. The field of network security is a dynamic one, with new protocols and updates to existing protocols popping up regularly. Although many of the security measures currently in use are firmly grounded in the concepts described in Part I, today's protocols are not without their differences.
Amongst protocols intended to run on TCP/IP networks, the layered architecture of such networks is one clear source of variation. Security measures can be implemented in nearly any layer of the TCP/IP protocol suite; there are security protocols for the link, network, transport, and application layers. Each of these layers offers its own set of merits, but this article focuses on protocols running at the transport layer.
SSL (secure sockets layer) is probably the most widely recognized transport-layer security protocol. A case can be made, though, that SSL does not technically reside at the transport layer. The protocol occupies what could be considered an intermediate layer sandwiched between the transport and application layers. Web servers, e-mail clients, and other network applications running on an SSL-enabled device pass their data to SSL software rather than directly to transport-layer software. The data is encrypted by the SSL software and possibly subjected to other security-related operations before being forwarded on to the transport layer.
SSL, much like the networks in which it operates, is layered. As indicated below, SSL's bottom layer comprises what is known as the record protocol. Messages from the upper layer of SSL are encrypted by the record protocol, which is also responsible for generating MACs to help ensure the integrity of upper-layer data. The record protocol sends encrypted messages on to the transport layer of the TCP/IP protocol suite, and from there they progress through the lower layers and into the network.
Data sent to the record protocol can come from any of four different sources. Three of the sources are protocols defined as part of SSL: the handshake protocol, the change cipher spec protocol, and the alert protocol. The fourth source consists of TCP/IP application-layer protocols, like HTTP and SMTP. Through SSL, developers working with application-layer protocols have a relatively straightforward mechanism for achieving secure communication.
Before any sort of application data can be exchanged between two SSL-enabled devices, the pair must negotiate the parameters of their secure communication channel. This negotiation, the steps of which are illustrated below, is referred to as a handshake, and, not surprisingly, it involves SSL's handshake protocol. As a handshake begins, two communicating entities agree to a cryptographic algorithm (since SSL supports several), and they exchange information that will be used to generate the keys required by the algorithm. Each communicating entity also has the option of authenticating the other by requesting a certificate.
After selecting a cryptographic algorithm and possibly performing authentication, both of the parties involved in a handshake send a message from the change cipher spec protocol. This message simply indicates that its receiver should begin using the previously chosen algorithm. (A cipher spec is another term for a cryptographic algorithm.) The parties then only need to transmit a few closing messages before beginning to securely send and receive their own data. If at any time during the handshake or the ensuing data exchange errors occur, they can be signaled using the SSL alert protocol.
Handshaking and data exchange in another transport-layer security protocol, TLS (which, aptly enough, stands for transport-layer security), closely mirror the analogous operations in SSL.The similarity is not coincidental; TLS is actually based on SSL. Although the original developer of SSL, Netscape, discontinued updates to the protocol after the 1996 release of SSL v3.0, TLS is still evolving, with the latest version, TLS v1.2, making its debut in 2008. This new version of TLS offers a number of advantages over previous versions and over SSL.
For a developer who plans to use SSL, TLS, or both in a new embedded device, the strategy of implementing these protocols from scratch has significant drawbacks. Although this article's descriptions of the protocols are somewhat simple, the protocols themselves present a number of challenges to prospective implementers. One of the most notable challenges is posed by the cryptographic algorithms that are central to the protocols: there are obvious reasons for developers who have little experience with cryptography to avoid attempts to implement these algorithms.
Developers seeking an alternative to implementing cryptography in-house can turn to libraries that contain implementations of popular cryptographic algorithms. A number of embedded software providers offer such libraries, as do many hardware and tool vendors. Cryptographic libraries from open source communities are also available.
Not all cryptographic libraries are of the same quality, but the best written of these pieces of software can spare a developer the sort of prolonged effort that is often required to implement encryption and decryption. For developers who are looking to save even more time, there are modules that implement security protocols in their entirety, as opposed to providing a solution for cryptography alone. Complete SSL and TLS modules are available from many of the same sources that offer cryptographic libraries.
While some providers of SSL and TLS implementations allow developers to purchase the security modules alone, other vendors only offer the modules as part of an operating system encompassing a variety of additional components, such as a TCP/IP stack and a real-time kernel. In any case, SSL and TLS must be used with a reliable transport-layer protocol (such as TCP), and a TCP/IP stack represents a relatively easy way of meeting that requirement. Developers with a security module that was not accompanied by a stack should make sure that whatever TCP/IP implementation they ultimately decide to use is compatible with their module.
The application code for a project that incorporates both a stack and a security module typically invokes the security module's functions directly when secure transmissions and receptions must be made. SSL and TLS modules do not all use the same API (application programming interface). However, many existing network applications were written around the OpenSSL API (which comes from the open-source security module of the same name), so developers concerned with writing portable code should look for security modules that offer OpenSSL compatibility.
As the below example code indicates, the function calls needed to send and receive data through a security module that supports OpenSSL closely resemble the calls that would be made in the module's absence. The example call to SSL_read() is essentially the secure version of a call to the BSD socket function recv(). Likewise SSL_write() serves as the secure equivalent of send().
result = SSL_read(ssl, buffer, bytes);
result = SSL_write(ssl, buffer, bytes);
Although an easy-to-use interface is important, APIs represent just one of many issues that should be considered by embedded developers who are looking for a security module to use in an upcoming project. Since the cryptographic algorithms executed by security modules are math-intensive, performance is another such issue. A module with a functionally correct implementation of a particular cryptographic algorithm can still cause problems for developers if the algorithm is implemented inefficiently.
In addition to varying from implementation to implementation, performance is algorithm-specific; some cryptographic algorithms are inherently faster than others. Additionally, algorithm performance may vary based on what sort of data is being encrypted or decrypted. The algorithms known as block ciphers operate on one fixed-size block of data at a time, so they are a poor choice for sending and receiving messages that are smaller than this block size. Stream ciphers provide better performance for such messages.
The documentation accompanying a security module should provide an explanation of which cryptographic algorithms the module supports. Also provided in the documentation should be a listing of the specific protocols implemented by the module. If for instance, the module implements SSL v3.0 and TLS v1.0, these protocols should be listed in the documentation.
The performance of a network application is usually influenced more by the cryptographic algorithm the application employs than by the particular version of SSL or TLS that the application's security module implements. Still, developers should not ignore information on protocol support when selecting a security module. The use of a module running outdated protocols can nullify all efforts to secure a device.
Along with protocol support and performance, memory usage is another important issue for developers seeking to secure an embedded device. Memory can become a major problem for embedded systems developers who use a module that was originally intended to run on a PC. In addition to consuming memory resources wastefully, these modules tend to perform poorly. Modules written for embedded platforms, on the other hand, are generally efficient performers, and many are scalable, allowing developers to optimize resource usage for a particular system.
Connect to the future
Not so long ago, few embedded systems had the computing horsepower to execute popular encryption algorithms, no matter how efficiently implemented. Thus, a substantial portion of the embedded community has not been exposed to the ins and outs of network security. Some developers will probably never have a need for knowledge of this topic. However, with demand for connected devices of all sorts continuing to grow inexorably, there are plenty of developers who will soon be encountering network security in their work. Those who make an effort to learn fundamental security concepts and who avail themselves of the sort of software modules described in this article will be well equipped to meet the challenges of securing embedded devices.
Matt Gordon is a senior applications engineer at Micrium, Inc.
1) Dierks, T., and E. Rescorla. "RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2." .
2) Kurose, James F., and Keith W. Ross. Computer Networking: A Top-Down Approach Featuring the Internet, Third Edition. Pearson Education, 2005.
3) Stallings, William. "SSL: Foundation for Web Security." The Internet Protocol Journal, Volume 1, Number 1, June 1998.