In a world filled with PPT presentations, some phenomena are quite interesting. For example, maybe your girlfriend has never heard of what an embedded system is, but she definitely knows what the Internet of Things (IoT) is; even if she doesn’t know that “the Internet has no privacy,” she surely knows that “the most critical aspect of the IoT is security”—as the saying goes, after hearing enough stories, even Einstein’s driver can explain relativity. So the question arises:
As a professional, what is the security of the IoT? Can you explain it clearly?
Alright, alright, stop pretending; we know you don’t understand anything. If you disagree, please skip this article. Now, let’s start with a few common misconceptions and slowly unfold the topic for you:
Misconception 1: Security and Safety
In English, there are two words that correspond to the Chinese term for “security”: Security and Safety. First, I want to emphasize:
Security and Safety are not synonymous; they have completely different definitions in many fields.
Not to mention ordinary people, even many engineering experts may not be able to clearly explain their differences—the reason is simple: different industrial standards have completely different definitions for Security and Safety (mainly Safety). Depending on the textbooks they hold, you cannot blame engineers for having different understandings of security.
Does this mean that outside of specific fields, Security and Safety are just a muddled concept for ordinary people? Not really. Detached from specific field dogmas, Security and Safety have some principles worth grasping:
-
Security is essentially equivalent to “information security,” while Safety is essentially equivalent to “functional/facility safety.”
-
Security mainly discusses how to ensure that information is not stolen by others.
In everyday life, Security is about how to prevent the neighbor, Mr. Wang.
-
Safety mainly discusses how to ensure that under extreme conditions, equipment or facilities do not malfunction, do not cause damage or harm; and may still provide a minimum level of functionality. Here are a few examples:
-
When someone gets electrocuted, the home’s automatic circuit breaker will cut off the power (overcurrent protection).
-
When the temperature is too low, to protect the lifespan of the lithium battery, some responsible electronic devices will prevent you from charging or discharging. For example, a certain phone cannot be charged in winter until it is warmed up in the blanket (low-temperature protection).
-
Some industrial-grade chips will automatically pull down the reset signal to prevent the system from malfunctioning if the system voltage is too low (BOD).
-
Security prevents malicious human attacks; Safety prevents damage caused by extreme environmental variables.
-
Sometimes, both Safety and Security need to be satisfied. Taking cars as an example, traditional cars emphasize Safety—how to avoid traffic accidents, how to reduce casualties; Security probably only relates to the car key, at most preventing second-hand car dealers from tampering with the mileage. In the “PPT” era, cars can now connect to the internet, and if Security is not taken seriously, once a hacker controls the car, traffic accidents and casualties are hard to avoid—making Safety irrelevant.
-
Sometimes, Security can be compromised in favor of Safety.
It’s like being tied to a tiger bench by a thug; what password for a safe can you refuse to say?
In an embedded system (or in an IoT system), what do Security and Safety refer to? What is their relationship?
-
In embedded systems, the scope of Security is not something that can be fully covered in today’s article.
There is information security in communication, which includes familiar aspects like 1) the encryption and decryption of various communication contents, and 2) the handshake and authentication between both parties in communication (similar to proving your mother is your mother, and you are her child).
Software has its information security, such as how to ensure that the code you write cannot be read by others; how to securely store the keys you use for communication; how to ensure that the libraries you co-write with others cannot be used without authorization, etc.
Systems have their security, such as how to ensure that the contents of FLASH cannot be directly read by others, how to ensure that the algorithm logic (timing) of a certain hardware IP cannot be obtained by hackers, how to ensure that different tasks cannot read each other’s contents without authorization, etc.
We will slowly discuss these topics later.
-
Safety in a pure embedded system can be understood as functional safety of infrastructure. What does this mean? It means that under extreme temperatures, voltages, currents, or noisy clocks, the system should not malfunction and should still provide a minimum level of functionality.
-
Security, in essence, is just a functional logic. The normal functioning of functional logic is based on the hardware working properly. Hackers often think, since I can’t break a normally functioning Security logic, let’s attack the hardware infrastructure that implements the Security logic—if the Safety of the infrastructure is not strong enough and is easily damaged. As the saying goes, if the skin is gone, the hair will have nothing to attach to; the Security built on it cannot function normally, thus exposing more attack opportunities. For this reason, we say:
-
In embedded systems, Security is built on the foundation of Safety. Without the Safety of the infrastructure, Security is just a paper tiger—this is why we often see that many methods of attacking Security actually first attack Safety. Many articles discussing Security inevitably also discuss many aspects of Safety. This can easily lead readers to believe that Safety and Security are the same thing in embedded systems. Now you know, they are not the same; it’s like saying “cutting the bottom of the pot does not mean that firewood and ‘cooking’ are the same thing.”
Attacking the reset circuit once allowed a well-known manufacturer’s Cortex-M3 microcontroller to be cracked in no time—that’s a typical case of attacking upper-layer Security through attacking hardware infrastructure. In fact, did you know that software also has infrastructure, and attacking software infrastructure is also a common tactic for hackers?
The stack is the infrastructure of the C language; whether it’s function calls, parameter passing, or local variable allocation, it all relies on the stack, hence various stack attacks, such as classic stack smash, code injection, etc.; similarly, the heap and C standard library are also software infrastructures.
In principle, many Security attacks and defenses are actually battles targeting the soft and hard infrastructure—cutting the bottom of the pot is simple and effective—however, this is just the tip of the iceberg of Security.
If you want to know what Security is specifically about, how Security operates in theoretical models and engineering practices, feel free to follow my public account; we’ll chat again next time.
—————End of Main Text—————
If you like my thinking, feel free to subscribe to Bare Machine Thinking
Copyright belongs to Bare Machine Thinking (under the Shakid Child Book Studio public account)
All content is original; any form of reproduction is strictly prohibited; sharing/forwarding is welcome
(The difference between reproduction and sharing is: reproduction extracts the article content and publishes it on other media; sharing still focuses on the Bare Machine Thinking public account, spreading the article)
