Above this there is wireless stack, and then the set of applications to be run on the node. This is the kind of network that is normally used in home or industrial automation for the nodes to communicate with each other. Some of the technologies in this category include ZigBee, Z-Wave, EnOcean and SNAP. SNAP is the technology that has been chosen by Google for its Android@Home project—a smart home-like effort.
So, we have standard Internet-level networks like TCP/IP on one side, and LoWPANs on the other. However, in order to move closer to the Internet of Things, we need all the nodes in the LoWPAN to also be Internet-capable and have their own Internet address—so that we can access and control these nodes from anywhere in the world using any device connected to the Internet (like a computer or a mobile phone).
This problem is not as easy as it sounds, because the size of the packets in the standard network can range from 1500 to 9000+ bytes, while the packets in the LoWPAN are only 127 bytes in size. LoWPANs also have lower data bandwidths and low power. As a result of some industry efforts, we now have an open standard called 6LoWPAN (where the ‘6’ stands for IPv6), which describes how to take a large packet from a standard Internet-level network and strip it down by removing a lot of high-level complexity and redundancy, to make it small enough for handling by the LoWPAN.
The 6LoWPAN specifiation also describes how to take small LoWPAN packets and reformat them for passing on to a higher-level network. So, it is expected that we will soon see 6LoWPAN wireless protocol stacks. However, some challenges related to creating and deploying applications based on this standard are to be ironed out before this happens.
Keeping away the snoopers
When we speak of embedded Internet systems—be it in a mobile phone or in a television, security is a key issue. Especially, when you think about the context of an Internet of Things, where all ambient objects have computers embedded in them, and will be connected to the Internet and to other objects around them including your own computer, the points of ‘break-in’ also increase. In the worst case, your microwave or washing machine could serve as the unguarded back entrance for somebody to break into your computer and steal all your confidential data. Hence protection from malicious access is an important aspect of designing and developing embedded Internet systems.
Sable shares an example, “With the power of embedded devices in the car infotainment space, hackers can take control over the system and remotely take control of your car. In some cases, the compromise of personal information can cause unwanted distress as well. The current-day embedded systems are a mixed bag when it comes to security; some handle it well, others don’t.”
There are such many situations where the security challenge deepens in the case of embedded systems. For example, where an Internet-enabled device needs to connect to an untrusted foreign network, say a wireless access point at an airport. The cryptographic algorithms should be powerful enough to allow sufficient security, while still having low power consumption and capable of running on systems with resource restrictions. “There are other scenarios where the security weakness could stem from the basic Internet protocol itself (say like HyperText Transfer Protocol (HTTP) streaming from a Web service in which a firewall cannot filter sensitive transmission) and needs additional layers of security,” adds Mani.
While these sound similar to the security issues faced by personal computers and other larger systems, the challenge transforms into a catch-22 in the case of embedded systems—the security algorithms need to be very comprehensive because of the real-time nature of embedded system operations; yet they need to be small and low-power.
Prof. Anupama explains, “Embedded devices are low-power, small-sized and energy-hungry devices. The security algorithms available in the market are processor hungry, which contradicts the basic axioms of the embedded devices. The current encryption and decryption algorithms are complex and require high processing power, and hence cannot be implemented easily on the low processing capability embedded devices. Making the embedded devices complex is not a solution as this will only increase the price of the devices—easy-to-implement encryption and decryption algorithms need to be developed.”
To overcome these challenges and incorporate the required levels of security consistent analysis and audits throughout the product engineering lifecycle would be required. It would require the setting up of a holistic security mechanism, working from the design/architecture upwards.
