Introduction to SoC Security Fundamentals; SoC Security Tutorial
-Aviral Mittal avimit att yahu dat cam.
https://www.linkedin.com/in/avimit/
SITE HOME


SoC Security -> Demystified. Security on SoC by someone who isn't a Security Expert.

Why read this techerature? Whats different?
Agreed, there are countless articles on this topic littered all over the internet, however when I read any of them, I realize that these articles assume that you already a know a lot about security. So I then wrote this one, which uses no-jargon, and no difficult words which security guys assume you know by birth. Sometimes it helps to follow someone on a topic who isn't an expert on that topic, for the reason that we can talk in same language, same frequency and remain on the same page. So here I present an article on SoC security written in plain text as opposed to binary.
However I must say that though the article is quite general in nature, but it does tend to be based around SoCs that use ARM's Cortex-M class processors, so at times the ARM element would appear.

So why on earth the System-on-chip needs to be 'secured', and what does it mean at the first place when we say that the SoC needs to be 'secured'. What is the threat?
Its very simple : Someone stealing IP. Software IP. Other threat is, someone trying to steal data. Yet another threat, someone trying to take control of your devices. Or Someone accessing something which someone is not authorized to access.
The security experts call it a 'security-model'. That is to say, what is the threat, how an hacker can attempt to steal/hack/hijack a device. That is what a 'security-model' is.
Once the threats have been analyzed, then engineers develop ways to protect against that. They design the SoC so that the SoC can fend-off those attacks.
But let it be clear. No SoC is 100% secure. By designing a SoC which can fend-off attacks successfully, we are only making sure that the cost of a successful attack becomes significantly higher than the cost of developing the assets under threat. That is all what the SoC security is all about. What's the point in spending 1 Million $ to steal something worth a tenner or so?
The other thing to note is: What is secure today won't remain as secure in future. As the computing power becomes cheaper, the computing power that is worth a million today may become worth a tenner or so tomorrow. Hence no security solution on a SoC today is a diamond. (BTW if you have forgotten diamonds are for ever.... :)


SoC Security : Deep Dive.
The SoC designer/Manufacturer produces a SoC which has software running on it.
Software/firmware can come from the SoC Manufacturer or from a third party, or even from anyone. Every one on this planet is now writing some 'app' which runs on smart phone. Imagine the threat, if an user written app can access the camera on your smart phone, and stream the data from camera away using phone's internet connection, you wont' be very happy.
So this App software must only have limited rights. It must not have right to access the phone's connectivity system and start streaming data from it away from the phone. So in plain and simple terms, this could be one of the objectives for the software to 'limit' the 'rights' of apps running on your device.

One thing is clear. The processor must be able to make out which software is 'good' and which is 'bad'.
Now processor is a dumb machine, so its our job to tell it everytime it starts to run something, that this is 'good' or 'bad'.

One way this could be done is to make the software able to 'authenticate' it self.
Another way will be to keep 'good' and 'bad' software at different 'regions' in memory, and tell the processor that if the software its running is from 'good' region it can do everything or most of the things, however if it is from 'bad' region, its very limited in what in can do or access within the system.
Any software that the processor will run, must be kept somewhere in memory (non-volatile memory, NVM), and usually the software or portions of the software will be first copied into processor's RAM (volatile) memory, and then the processor will execute this software code from memory. There is also a possibility that the software may be executed directly from NVM, i.e. without being copied into RAM. But that is not the point here. The point is, the 'good' and 'bad' software must be kept at different 'regions' in memory so that when the processor executes them, it knows if it is fetching the software from 'good' or 'bad' region. Having said this, the processor must first be made aware of these 'regions' so that at the execution time it can scrutinize the memory addresses it is executing the code from, and decide if it is 'good' or 'bad' software, and then further decide, what this software is allowed or not allowed to do.

Now when the processor first starts, i.e. comes out of reset, it has no idea about anything 'good' or 'bad', hence the software that is executed at startup i.e. when it boots, must be 'good' software.
So the first thing that the system designer must do is to ensure the above.
In ARM-Cortex-M world, the software starts to execute from memory location 0x0000_0000.
The first location is treated as a special location, and the contents stored here are treated as the value with which the processor's stack-pointer must be loaded with.
The second location 0x0000_0004 : This is the location which is called the location which points to the 'Reset_Handler'
The processor will jump to the location which is written at 0x0000_0004
For example consider the following 2 instructions.
0x0000_0000 2000_4000
0x0000_0004 0000_8000
This means that at power-up the processor will start its execution from 0x0000_0000, it will load the value written at this memory location i.e 0x2000_0000 into its stack pointer.
Then it will fetch the value at location 0x0000_0004 , and make a jump there, and start executing code from this location i.e from 0x0000_8000 in this example.

Usually the program code starting from 0x0000_0000 is kept in on-chip ROM, i.e. Read-Only-Memory which is built inside the chip. The program is fused into this ROM at the time of manufacturing the SoC. Hence it is 'good' code, as long as the Manufacturing process can be trusted, which usually is trusted.

Its nearly impossible to hack the ROM cost effectively. So this is the securest from of code that the processor will ever run. Hence it is also called 'Root-Of-Trust (RoT)'. In a hypothetical case if all the software is kept in ROM it will be very secure. But it provides 0 flexibility. The whole point of the processor is to be able to execute code written by users ages after it is manufactured. Also the data that a processor or system using a processor will always want to change/process the data. After all a computer is a data processing machine. Almost all the use-cases of processors on a computer or a smart phone or devices must be able to process the data. So a computer with just a ROM isn't a feasible proposition.

Usually a system-on-chip will always have some ROM, but most of the software will then be stored in some kind of non-volatile memory either on-chip or off-chip. The ROM may have a bare-minimum code what will allow the system to do some essential things, for example set-up the system so that the processor can start fetching code from non-volatile memory such as Flash memory which can be either On-Chip or Off-Chip. OR the ROM may be big, and may do a lot more than just bare-minimum. However all modern SoCs have some kind of NVM e.g Flash, R-Ram etc.

Off-Chip memory is a big problem.

Off-Chip Code encryption/decryption
System-on-chip will typically have some sort of non-volatile-memory (NVM).  The code in the NVM can either be directly executed from NVM, or it can be copied from NVM to RAM before execution.
But in either condition, if the NVM is off-chip, the software in the NVM must be encrypted.
The encryption method however will be different depending upon if XIP (execute-in-place) from off-chip NVM Device is a required.
Ok, how are the ROM and NVM related?
Code in ROM being on-chip, is the most secure code. This code may be made capable enough to do the following:
This will enable the SoC to use the NVM code in a 'trustworthy manner'. ROM contains secure and trusted code. The code in ROM knows
It is to be noted that the 'decryption' can be done by software alone, or hardware may be used for it. If there is any hardware use, these hardware blocks are typically called 'hardware accelerators'. So a user may find system on chip with hardware security engines, or hardware security accelerators or 'crypto hardware' or a name with any combinaiton of these. They are there to help in encryption/decryption.
From hardware point of view, in addition to 'cryptography hardware accelerators'  there is another component,  something called TRNG, True Random Number Generator, which is worth taking a note of.
The main function of this block is to generate a 'true' random number. One of the use of the random number is to assist in authentication, as explained in this techerature article.

Chain of Trust:
This can now establish a chain of trust, starting with the ROM code.
Now the code in the NVM, which may be the main 'application' code can further program other regions of the memory in the system and designate them as 'privileged', 'non-privileged' and in addition to it, if the processor supports secure/non-secure as in ARM processors built on ARM v8 architecture, which is often also called ARM Trust Zone, can partition the memory into 'secured' and 'non-secured' in addition to 'privileged' and 'non-privileged'.

Partitioning the memory into these kind of regions, gives the power to the designer to be able to limit the non-trusted code, as by careful design, while executing any non-trusted code, this code will only be assigned very limited capabilities. It wont be able to read/write into any secure regions, read/write any critical data or code. Hence the system is considered relatively safe.
This partitioning of memory brings us to our next chapter. Access Protection.

Trusted/Untrusted Vs Secure/non-secure.
From the point of view of identification of the code  in ARM's world, there is no difference between Trusted and Secure software and untrusted and non-secure software. These terms are used interchangeably.


Click Here to Make Comments or ask Questions
                                                                      
<= PREV  : Debug Authentication.                                      Next Access Protection =>

SITE HOME




--------------
Random Data:
Integrity Checks: Calculate hash value of memory 'blocks' at boot, store the 'hash' values in a table. Then at run time again calculate the hash values of the blocks then compare it with those stored in table. If they dont match, the system has been compromised.

















On a SoC, the clock control, power management flash programing should be under controlled access. Only software running in privileged mode is ever allowed to access these.