By: Ariel Shulman, Connect One
Embedded applications increasingly involve distributed nodes connected via wireless LANs and via the Internet. A “firewall on a chip” can help keep communications secure and protect applications from attack while not overburdening the CPU.
With the great benefits that come from connecting to the Internet, users expose themselves to different and new kinds of risks. Information sent over the Internet must be protected to ensure that an individual’s or a company’s private information—whether financial or otherwise—will be safe from viewing and/or exploitation. Encryption is essential.
When a device is provided with Internet connectivity, it encounters this same level of risk as well. Suddenly, others can connect to it and gain the ability to use or misuse the device’s data or to otherwise sabotage the functionality of the overall system. Once again, protection is necessary. Just as a firewall is needed to protect your PC from unsolicited connection attempts, so developers must protect Internet-connected devices using firewall technology.
Wireless Connectivity – Different Solutions for Different Needs
Basic protection challenges become even greater when technology goes wireless. These days, wireless technologies seem to be everywhere, and M2M solutions are no exception. Most M2M solutions rely on one wireless technology or another.
Different M2M solutions require different wireless connectivity methods. For example, fleet management applications for trucks moving about the country must rely on cellular networks, while inventory management solutions used within the confines of a warehouse can use wireless LAN.
Cellular networks such as GSM/GPRS/UMTS provide ubiquitous coverage over large distances, usually at low data rates and with no encryption capabilities. For some applications and industries, sending unencrypted data (i.e., GPS coordinates of a truck’s location) does not represent a significant business risk. However, for some Internet-connected devices transferring sensitive information such as medical patient records or credit card payment information, this is a serious problem since data can potentially be intercepted en route to its destination. Data sent over cellular networks is usually charged according to volume, which can make transfer of significant amounts of data quite costly.
Short-range wireless networks such as wireless LAN cover a significantly smaller range but at much higher data rates, frequently with some level of encryption. Data sent over wireless LAN networks is free of charge. The low cost, ease of deployment and acceptable level of security makes Wi-Fi an ideal choice for short-range wireless applications. Some mobile RFID readers are equipped with wireless LAN in order to relay information read from RFID tags back to a central server over the Wi-Fi connection.
No matter what the M2M solution is, the need for a secure communications path is becoming increasingly important, and in some industries, mandatory.
Wireless Security – The Devil Is in the Details
The issue of security in wireless networks is often misunderstood by M2M end users. Cellular networks usually cannot offer any kind of wireless security. The data is sent from a device in an unencrypted manner over the cellular network. Connection attempts from the cellular network to the device are possible.
Wireless LAN offers a higher level of security. It has evolved over the last few years to become a widely accepted form of communications. The introduction of the WPA2 encryption algorithm has finally addressed the security concerns of even the most paranoid of users.
WPA2 achieves this increased security by using strong encryption and authentication based on dynamic encryption keys and the Advanced Encryption Standard (AES) cipher as an alternative to the TKIP protocol. As such, it offers a superior level of security compared to its predecessor, the WEP protocol, which uses static keys and is no longer considered secure by many IT professionals. For many, a WPA2 security wireless LAN is now considered fully secure. However, even WPA2 may not be enough—not because it provides subpar encryption, but simply due to the fact that it is not able to encrypt data “end-to-end.”
Wireless security protocols such as WPA2 ensure a fully secure data communication path over the air, starting with the client device and ranging all the way to the access point. Security can be breached when any information leaves the boundaries of the wireless network.
If a wireless LAN device transfers information to the public Internet, the data is not encrypted at this point. This is because WPA2 is implemented in both the client device and the access point, but not on any Internet server. In other words, the access points exchange encrypted packets with the client device over the Wireless LAN network, but once data is sent from the access point on to the Internet, it is no longer encrypted.
To ensure end-to-end encryption, an additional encryption method must be used. The most widely used and most trusted solution is the secure socket layer (SSL) protocol. The SSL protocol is the de-facto standard for secure Internet communications and has been used for anything from Internet banking to transfer of medical data.
Although the SSL protocol provides excellent encryption that can potentially replace wireless security algorithms, most customers choose to use both methods simultaneously. For example, many hospitals use wireless LAN networks to provide connectivity for mobile medical devices. Since these devices need to send important and confidential patient records over the Internet, they typically use end-to-end SSL encryption or another form of encryption over the Wi-Fi network. These measures are necessary to prevent unauthorized connection attempts by patients or other visitors.
In contrast, cellular networks are inherently insecure. With them, the only solution for encrypting data sent over the networks is the use of an end-to-end encryption solution such as SSL. Many point-of-sale (POS) terminals use cellular technologies to transfer credit card data, such as isolated vending machines or customers buying train tickets after boarding the train.
Wireless Internet Security Easier Said Than Done
An M2M solution cannot be considered fully secure unless it satisfies two conditions:
1. It communicates in a fully encrypted manner and
2. It is protected from Internet attacks
In existing M2M embedded solutions, the application runs on existing hardware with its own operating system. Development of end-to-end SSL encryption capabilities is usually an expensive and time-consuming process. Upgrading existing designs with a higher level of security by adding new encryption and security protocols to the application means that a new processor may be needed because connectivity and encryption are CPU-intensive.
In addition to CPU cycles, additional system memory is required since networking and encryption add significantly more code that has to run concurrently with the host application. Many commercially available SSL3 software stacks are over 500 Kbytes in size, and open-source packages are much larger. Also, memory must be allocated for buffers used to store transient data. Finally, the application must be rewritten, debugged, tested and released.
Similarly, it is equally challenging to secure an M2M application from Internet attacks. If a single microcontroller is used in a device to both run the application and to manage IP communication, all the resources of the microcontroller are fully utilized. As soon as the application is Internet connected, it is by definition exposed to Internet attacks, unless a dedicated and complex firewall is added on top of it.
As can be seen in Figure 1, using a CPU for the core application and networking functions results in Internet traffic directly hitting the CPU. Retrofitting the product with a larger controller is impossible. Replacing all devices in the field is cost-prohibitive, resulting in significant redesign and additional costs. Doing business the old way results in losing your competitive edge. Without the availability of onboard resources, the only solution is to find another alternative.
The Solution – An IP Controller
The use of a dedicated IP controller solution provides an immediate, cost-effective and highly secure solution. It allows M2M developers to focus on their companies’ core competencies while offloading all communications and security tasks to a field-proven solution. After being instructed by the host CPU to send encrypted data, the IP controller performs all the necessary functions to ensure that data is successfully sent using end-to-end SSL3 encryption.
To open a secure TCP socket, the IP controller first opens a standard TCP/IP socket to an SSL3 server, and then initiates an SSL3 handshake over the open socket. The IP controller requests a list of cipher suites ranked according to the client’s priority from the server. The server accepts the cipher that it supports and the client receives by default the server certificate to authenticate server. The server then provides a certificate signed by a Certificate Authority (CA) that the client recognizes and is preinstalled in the client. In some cases, client authentication is required by the server, whereby the client must send its signed certificate to the server. The server and client agree on encryption/decryption keys during this phase. This requires the exchange of random numbers between the client and server.
Following a successful SSL3 handshake, the IP controller encrypts all data sent across the socket according to the cipher suite and keys agreed upon during the SSL3 connection. Data received on the socket then is decrypted by the IP controller.
As one can see from this description, the IP controller saves the M2M developer a significant amount of the programming required for SSL3 encrypted communications. Thus, the use of an IP controller greatly facilitates meeting the first condition for secure M2M communications—that of communicating in a fully secure manner.
The IP controller also provides an immediate answer to the second condition of protecting the embedded device from Internet attacks. The host CPU simply sends text commands to the IP controller and does not have any direct interaction with Internet traffic. In other words, it is not hit with any packet from the Internet; there are no shared memory spaces, or other ways for an attacker to reach the host CPU and its application. Furthermore, since the IP controller is a slave coprocessor, it is unable to initiate any connection to the host. This combination means that the IP controller is in fact an impenetrable firewall, protecting the embedded application from Internet attacks.
Any MCU/CPU, no matter how simple—even existing or legacy solutions already implemented in existing devices—can issue simple text-based commands in order to instruct the IP controller to perform complex tasks such as establishing an encrypted TCP connection to a remote server, or uploading an encrypted file to a remote server. In addition, the IP controller servers as a “firewall on a chip,” shielding the application from malicious attacks originating from the Internet. Figure 3 provides a block diagram of an IP controller in a wireless M2M system. The IP controller contains all the drivers, encryption and security algorithms required to manage either cellular or Wireless LAN communications. It communicates with these devices using either USB or SPI, depending on the wireless device used.
Migrating M2M applications to use wireless networks, either wireless LAN or cellular, requires the designer to be familiar with security issues. In today’s world, a robust and reliable security solution is absolutely necessary. Since Internet connectivity probably is not his field of expertise, the designer must ask many questions, including how much risk is he ready to take if he has limited experience with IP networks.
There are many hard, soft and hidden costs that can add to the total cost of implementing a secure wireless M2M application. IP controllers provide an immediate, field-proven solution and greatly expedite and facilitate the introduction of new M2M solutions.
San Jose, CA.
© 2009 RTC Group, Inc., 905 Calle Amanecer, Suite 250, San Clemente, CA 92673