Quantcast
Channel: Blogs at All About Circuits
Viewing all articles
Browse latest Browse all 742

Lightweight Cryptography for Embedded Systems in the IoT

$
0
0
Abstract:

It is widely recognized that data security will play a central role in the design of future IT systems. Many of those IT applications will be realized as embedded systems which rely heavily on security mechanisms. Examples include security for wireless phones, wireless computing, pay-TV, and copy protection schemes for audio/video consumer products and digital cinemas. Note that a large share of those embedded applications will be wireless, which makes the communication channel especially vulnerable. All modern security protocols use symmetric-key and public-key algorithms. This contribution surveys several important cryptographic concepts and their relevance to embedded system applications. We give an overview of the previous work in the area of embedded systems and cryptography.


Vulnerabilities of Embedded Systems

Embedded systems are vulnerable to assault for several reasons, the chief ones being their connectivity, accessibility and low availability of resources to support security and authentication.

It is estimated that by 2020, there will be 28 billion embedded systems connected to the internet. With greater connectivity comes an increased risk of being attacked. Every communication node becomes a potential weakness. Failure of any one embedded system can create cascading events that, in extreme cases, can bring down entire networks – say, a bank’s ATM machines or a power grid.

Further, devices with embedded systems are often physically easy to access. Products like laser printers, refrigerators, gas and electric meters, insulin pumps, surveillance cameras and door locks are almost never located behind gates or barriers. This makes it convenient for a hacker to see the results of their actions unfold in real time and adjust their attack in the field.

Although embedded systems are easy targets of attack, their security lags far behind that of, say, PCs and servers. Embedded system security is at about the same stage that PC security was in the 1990s, when the Internet was starting to become commercialized. That said, as embedded systems have grown more complex and integral to the IoT, vendors are now scrambling to strengthen security.


Cryptography Suited to Low-Resource Embedded Systems

One of the hurdles to effective encryption is the limited resources available in embedded systems. While devices with adequate power supplies and computing resources, like PCs, can run security protocols rapidly, embedded processors, which have far less power and processing capacity, take longer. Because of the systems’ small processing capabilities, some cryptography researchers have proposed hardening them with ECC protocols.

Our benchmarking and recent publications show that ECC has several drawbacks in securing low-resource devices like embedded systems. For example, the 8- or 16-bit processors typically used in embedded systems do not have the resources to run ECC for authentication, identification and data protection in short timeframes.

Secure RF’s cryptographic solutions for embedded systems are based on Group Theoretic Cryptography. They run up to 63 times faster than ECC while using less than 1% of the power ECC requires, and are quantum-resistant. Our Walnut DSA algorithm, a lightweight digital signature signature authentication scheme, is among those that have been presented at NIST workshops as it develops cryptographic standards for constrained devices.

Secure Execution Interval (SEI)

The need for SEIs arises from the fact that a mechanism is required to prevent any malicious interference towards the tasks that are necessary for providing the safety guarantees. After a restart, while all the external interfaces of the system remain disabled, the system software is loaded into memory from a read-only storage unit. Disabling interfaces isolates the system and protects it from intruders. So long as the system is isolated, we assume that the software is uncorrupted. SEI refers to this isolated interval of time after each restart. During the SEI, two tasks execute in parallel: SC (which runs periodically to keep the physical system stable) and Find Restart Time (Section IV-C). If Find Restart Time cannot find a safe restart time (this may occur when the physical plant is very close to being in the inadmissible region), SEI is extended for another Ts time units5. Extending SEI gives SC more time to push the state further away from the unsafe boundary and into the admissible region. If Find Restart Time task is able to find a restart time, (a) the Set Restart Time interface of the RoT (details in next section) is used to set the time for the next restart event, (b) SEI terminates, (c) all the interfaces are activated, (d) the main controller of the system is activated and (e) the system enters normal operation mode – until the next restart takes place. Note that following this procedure, the Set Restart Time interface of RoT will be called exactly once before the SEI terminates.


Hardware Root of Trust (RoT):

Our design requires a mechanism to ensure that under any circumstances, the adversary cannot prevent the system from restarting. Hence, we include an isolated HW module in charge of triggering restarts and refer to it as hardware root of trust (RoT). RoT provides a hardware interface, Set Restart Time, that during the SEI allows the processor to set the time of the next restart event. To achieve this, after each restart, RoT allows the processor to call the Set Restart Time interface only once. Additional calls to this interface will be ignored. RoT immediately sets a timer for the time value received from Set Restart Time interface and issues a restart signal to the hardware restart pin of the platform upon its expiration. In order to achieve the security goals of the platform, ROT needs to be secure and incorruptible. Hence, we require hardware isolation (e.g., a standalone timer) and independence from the processor with no connectivity except for the HW interface set Restart Time. In our prototype implementation, RoT is implemented using a simple microcontroller.


CONCLUSION:

The aim of this paper was to provide a comparative analysis on lightweight crypto-graphic algorithms designed for resource-constrained devices. The inherently limited capabilities of these systems in terms of computing power, memory, storage and energy resources, inevitably limit the effectiveness and the applicability of well-established cryptographic mechanisms designed for systems where such resource constraints are not a significant concern. Such an extensive analysis is considered essential to those planning on utilizing such mechanisms in newly designed systems or applications running on resource constrained devices. As demonstrated in this work, there is on-going research on various aspects of lightweight cryptography. The evaluation of the robustness and efficiency of pre-existing as well as newly proposed schemes poses a major challenge to research and development efforts. Overcoming the challenges, how-ever, is necessary for realizing the ubiquitous computing future.

Viewing all articles
Browse latest Browse all 742

Trending Articles