Home Internet of Things Aerospace Apparel Energy Defense Health Care Logistics Manufacturing Retail

Sorting Out Security: Making Sense of Today's Solutions

Security at the process level is essential to creating an immunity to the cyberattacks of tomorrow.
By Jothy Rosenberg

Encryption and Cryptography
When a vendor says it has a "secure processor," what it means in today's world is that it has added encryption and maybe cryptographic key management to a standard processor or in a specialized co-processor. It does this in hardware to make it faster than running encryption software on the standard processor.

This is an example of communications security. Its "secure processors" ensure that any data going to and from the device is encrypted, making data theft or exfiltration impossible—or, at least, a huge amount of work for an attacker.

Encrypting communication is important, and even vital in many situations, but it doesn't warrant calling the processor a "secure processor," because it doesn't protect against attacks that prey on software vulnerabilities. Attackers can still exfiltrate data by bypassing encryption routines. An attacker can exploit a software vulnerability, execute a buffer overflow, inject code and take over the processor. Once that has occurred, securing communications becomes meaningless.

Some vendors offer processors with added security in the form of compartmentalization. This means they create isolated compartments inside of memory to separate trusted and untrusted areas. As a result, if an attacker can infiltrate the system, he or she is confined to a single compartment, constraining the amount of damage possible.

Compartmentalization may limit an attacker's impact, but it does not protect against the exploitation of software vulnerabilities in the first place. Moreover, it doesn't stop an attacker from finding and exploiting a vulnerability in the "trusted" area of memory—especially since, in practice, people are putting more and more code into these trusted areas that are still subject to the "15 bugs per thousand lines of code" rule.

Login and post your comment!

Not a member?

Signup for an account now to access all of the features of RFIDJournal.com!

Case Studies Features Best Practices How-Tos
Live Events Virtual Events Webinars
Simply enter a question for our experts.
RFID Journal LIVE! RFID in Health Care LIVE! LatAm LIVE! Brasil LIVE! Europe RFID Connect Virtual Events RFID Journal Awards Webinars Presentations