Emerging Security Protocols

As the proliferation of mobile devices ramps up at escalating rates, securing these devices and the infrastructure they run on is becoming a top priority for both the hardware and the data that swirls within it.

Traditional security platforms such as firewalls and antivirus programs are still a viable part of the security envelope, but the rapid emergence of zero-day/hour threats is something that traditional solutions can’t address. So the global approach is to become educated about gateway, firewall and other solutions, which can incorporate various protocol filters, policies and functionality that address security challenges unique to the IoE.

“How to incorporate security into protocols and standards is a hot topic today,” notes Chowdary Yanamadala, vice president of business development at ChaoLogix. “Of late, security is finally starting to come into the forefront with products like ‘Threat from Google.'”

That is good news because the IoE platform will require new and improved techniques to protect all vectors – hardware, software, and data. Any device that even has the remotest possibility of physical access to IoE networks is a potential security leak.

In addition, this practical realization of the IoE will require the maturation of any number of new platforms and technologies. These include but are not limited to sensing and actuation, distributed control, device tracking and process identification, communication protocols, computational sensing traffic and user modeling, semantic knowledge processing, and coordinated behavior. Add to that the demands that IoE subsystems will have to comply with numerous constraints, such as efficient power usage, life of the device, footprint, and environment.

Furthermore, along with these IoE components, will come unique security challenges. These include integrity events, the validity of physical signals, and authentication of devices. And, on top of all that will be the yottabytes of data that will be vulnerable to semantic attacks

However, across the board, within the security industry, and slowly across the enterprise, there is a consensus that security will be the most challenging of the requirements. As 50 million or more devices start to talk across a sea of interconnects, the potential for malicious attacks will proliferate as never before.

Slowly but surely, bleeding-edge solutions are emerging in that vein. Data-driven security is one, integrated firewalls in SoCs is another. “At the hardware end, placing the boot code in secure ROM at the lower end, to public/private key exchange, to complex, proprietary crypto algorithms at the higher end are all possibilities,” said Ted Marena, director of FPGA and system-on-chip marketing at Microsemi. There are other methods as well.

Distinct challenges
The largest percentage of devices in the future IoE is expected to be simple sensors. Such sensors will have limited security compute capabilities and may be located in difficult-to-access environments. That means that typical AES or similar algorithms cannot be used because these devices will be designed to use low CPU cycles, which will limit encryption processing capabilities.

“Bringing all of these devices together in the IoE will be a challenge. It will be different from the infrastructure of today. For example, the mobile phones infrastructure is very well understood, and thing work well together,” says Yanamadala. “But in the IoE, with 50 billion or more devices that are all interconnected, how do we bring all of this together in a way that the data, the platform, and the processes are all secured?”

Fig. 1. Source: Cisco

Another issue is that many of these devices will be deployed in installations that will require autonomous field operation. Such devices are likely to have no backup system, communication or otherwise. They can also have variable states of connect and disconnect. For example, articles of clothing may only be on the network when they are placed in the washing machine to tell the washer what they are and how to wash them. Or food products may only be online when they hit a variable, such as passing an expiration date, or to tell the oven how long and what temperature it needs to be cooked.

Other devices may need to be part of multi-party networks. A good example of that is a traffic light that may switch to another network deployed on emergency vehicles when it captures the signal during intersection proximity. Such devices have provisioning access and owner liability challenges.

Still another challenge is that devices may have longer lives than the security or other algorithm they are born with. Things like smart meters or smart appliances can last 10, 20, or more years. Such devices are not practical to update every time a new threat emerges, which, in some case, can be daily.

There is also the issue of physical protection and tamper resistance. What if the device is stolen and reverse engineered. Other devices such as water level, fire or vibration sensors may require 24/7 polling, which uses energy and is easily detected.

Other challenges include the fact that many IoE devices will be multi-user/ownership. The devices and management platforms where data is managed, or shared, can have multiple ownership, security policies, and connectivity/managerial domains.

This will require such devices to be able to have open access to any number of data platforms and controllers/managers, concurrently. At the same time, privacy must be upheld, exclusive of where or what data is being consumed. As well such devices will have to have information availability, yet concurrent data isolation between common controllers.

Fig. 2. Source: Microsemi.

Let’s go back to the traffic light for a moment. Let’s say the network that the light is on is undergoing a denial of service (DoS) attack, yet the input from the emergency vehicle must go though. The managing agent must be able to discern there is an issue at the light and have contingency plans in place. One such solution might be to shift control of the area to another manager that is not compromised. In addition, the mobile managing network of the emergency vehicle must be able to discern valid data from corrupt or lost data due to the DoS attack.

Overall this is quite a large order for the multitude of devices expected to be on the IoE. It becomes especially challenging with lower-order and simple devices. However, progress is being made and evolutionary as well revolutionary technologies are on the drawing board, some even in the pipeline already.

Some solutions
The good news is there is work being done on some new hardware-level security primitives. “If you do things in hardware, it tends to, generally, be much more efficient,” said Ramish Karri, professor of electrical and computer engineering and computer science and engineering at the Polytechnic School of Engineering, New York University. “Extrapolating that means it is possible to have much stronger protocols at higher levels.”

There are many avenues that can have applicability to this emerging universe. In the traffic light scenario, for example, a simple AI machine learning system could be implemented to compare the current scenario to a database of past scenarios, and extrapolate based on criterion learned from pools of available data, or past attacks. Complementary to this would be to strengthen network layers by implementing methodologies such DNSSEC on the DNS and DHCP structures, as well as deploy strong identity protection.

Another area involves physically unclonable functions (PUFs). “This is one area where primitives can enable higher level functions,” says Kerri. For example, advanced primitives can enable better chip biometrics for such things as face or palm recognition, which are being looked at for very strong security locks.

Still another direction is protocols for such areas as policy management. The ability to have tremendous processing power at our fingertips presents the case that different identities can develop complex relationships for security. “For example, these entities can develop non-trivial relationships between them that can be leveraged for things like policy workflows, which, in turn, can develop some extensive security properties,” says says Eve Maler, vice president of innovation and emerging technology at ForgeRock.

One example of that is in what is being called identity relationship management. “This is not just employees, it is not just customers, it is not just applications—it’s the relationships between millions and billions of devices that have their own identities,” says Maler. “Once you have all of these different identities, you start to get non-trivial, interesting relationships that can be leveraged for things like policy workflows that develop interesting security properties. This allows for the derivation of rules for platforms like access control and authorization, on a fairly dynamic basis.”

One of the benefits is that it extrapolates to a wide span of challenges for hackers to overcome, making it a very interesting direction for IoE security.

However, going back to the chip level where most agree security should be the first level, innovation is happening there, as well. And one of the more interesting areas is in on-chip firewalls.

Upping the firewall ante
The traditional firewall is a very effective methodology. But for the IoE, it requires rethinking. “One such application for firewalls is to sprinkle dozens, if not hundreds, of special function firewalls across the SoC fabric,” notes Kurt Shuler, vice president of marketing at Arteris. “You place the firewall between an initiator and target, or a CPU and memory, for example, and program it for a particular use case.”

In effect, there is criterion that challenges if the particular initiator is authorized to communicate with the specific target, such as packet inspection. “It also verifies that the particular data is valid, at the particular communication instance,” Shuler notes.

However, it isn’t just as simple as firing off an interrupt if the criterion isn’t met, and this is where the next level of intelligence comes in—stateful packet inspection and multiprotocol application inspection.

Typically if there is an activity and it results in an action that isn’t recognized by the firewall, such as the chip is being attacked, these firewalls are designed to initiate a low-profile action so the perpetrator doesn’t get tipped of that he has been discovered. This function is usually handled by some sort of security controller within the chip that talks to the firewalls.

Firewalls can be programmed to take any number of actions such as shut off certain areas of the chip, or run a routine to reroute the request to a null operation. Or they can simply block further activity until the anomaly has been neutralized. They even can render the chip useless. What is nice about this approach is that it can be implemented in hardware and it’s fairly scalable. That means it can scale down to some of the newer IoE devices that aren’t all that sophisticated and have light deployments of processors, memory, and storage.

New security directions
One of the more exciting directions involves new authentication schemes. One such scheme that NIST likes is the compact SHA-3. This particular approach is very well suited for embedded smart devices that will be hanging on the IoE, but which don’t have a lot of computational capabilities. The algorithm is relatively compact, which means it is basically pure code with only a hashing mechanism that turns whatever input it is fed into a unique, fixed length output. RSA, on the other hand, is an asymmetric encryption algorithm with two keys, and a digital signature algorithm.

While hashing code doesn’t deliver the full cryptography capability of other complex algorithms such as DES, RSA, or DH, it is still a fairly strong and computationally sophisticated enough to secure many of the low-tier IoE devices. And it can be implemented in hardware.

Lateral to that is a rather interesting solution in the form of data-driven security. Data-driven security is a huge field with a plethora of spokes that deal with the analysis of data and how to find and identify security anomalies that can be security breaches or just opportunities for breaches. Once identified the objective is to analyze such information and derive effective security layers to protect the data.

In general, there are several main aspects to this vector:

• Real-time analysis of the continuous data flows. This involves being able to identify, combine and manage various multiple sources of data and scale the data as it flows through the IoE.
• Develop advanced analytic models and algorithms that are capable of recognizing what is relative. This means moving away from current analysis models to ones that can apply predictive methodologies that can work on the refined data.
• Optimization of data so results are based on good decision making and provide meaningful data rather than just a bucket full of results. This involves developing a strategy of what one expects the data to unveil, what is the result expected to be relative to, and make sure there is a data analytic infrastructure in place that can handle the expectations.

This, of course is a birds-eye view of a very new perspective on securing data. The details of the points presented go very deep in concept, and space limits a more in-depth discussion. But the topic is fascinating and is a completely different approach to data, especially Big Data security.

Conclusion
This article barely scratched the surface of what is becoming a very hot topic. There are many players in this arena, and this topic will be discussed heavily in upcoming articles.

Emerging security protocols are being discussed at all levels, from the application to the middleware to the fabric of the chip. The IoE will present a completely reworked model for security simply because there will be so many different points of ingress.

Innovations are coming from all directions – from encryption algorithms to data analysis. It is an exciting time to be in the thick of it.