With the widespread adoption of IoT devices - from smart cities to wireless jewelery - the Internet of Things has infiltrated virtually every step of the day in everyday life, there is an ever-growing demand for IoT-based embedded systems to prioritize security priorities. Is the first step in protecting any embedded system and is an essential part of preventing malware barriers in your application Let's look at its pros and cons and take one of the common processors in the electronics industry - i.MX6 As an example to illustrate.
What is safe to start?
'Secure boot' is the process by which the operating system (OS) must authenticate against hardware prior to launching mirroring and code before it can be used for startup. Hardware must be prepared in advance in this way: it only Authentication uses code generated by trusted security credentials In summary, it ensures that boot-up and OS software are the intended manufacturer's version and not tampered with by malware or malicious third parties.
Safe boot devices for any single use, such as e-readers that make extensive use of i.MX6 processors such as the i.MX6 Solo and DuaLite integrated E-Ink display controllers, which are used primarily in Reading eBooks, not general operations, in which case it is helpful to lock the Linux environment at boot time.
Other things, such as Android phones, may be optional, for example, the use of secure boot may limit the end-user's ability to execute guest ROM. This may be a feature feature, or it may be based on product layout or security requirements Ideally, the ideal time to start with a safe boot is basically when you do not want the other party to load the operating system or other boot loader into your device.
More people will recommend safe boot to systems with higher levels of integration such as Linux IP cameras because any malicious boot code or operating system software can turn your device into a botnet Or perhaps the picture taken from the camera is publicly uploaded to the internet or even modified to include information such as the video clip the video host wants.
i.MX6 on the safe start-up process
Once the boot image has been set up on i.MX6, a secure key must be generated for the SSL certificate generated for this purpose in order to take advantage of the secure boot.
These keys are used to generate a set of security instructions and then compiled into the boot image using tools provided by vendors such as Freescale and NXP today.The processor then takes the first stage boot loader, And use your credentials to authenticate the credentials generated by the secure startup compilation tools.
When writing to the boot media, if the boot key image data matches the key data stored in the processor's secure storage, it will begin to execute the security command and then check the mirrored password hash value to make sure it matches the safety indication If they match, the processor will start loading and executing your boot image.
Once this process is started by the internal boot loader of the CPU, you can still invoke the secure boot library from the code that started the loader, which allows you to load the operating system image and start the loader with the CPU boot loader Program the same way to be certified.
At the end of this process, the operating system will start up in a verified, secure environment, which you know is reasonable because each stage performs a certification test of the key hash stored in the processor.
One-time programmable design
From the security point of view, this process generates a root key from the SSL certificate that is spurious and then burned into the CPU in a one-time programmable (OTP) design. Once the key is burned into the processor Can not change - one of the reasons is safety.
The boot image is also signed on the basis of the key, and the information generated during the signing process is combined with the image. The processor checks your image key with its key, and if it matches, The key checks your image. If it still matches, you can perform a mirror. This step will take you to a higher level chain, starting the load process from the CPU to the normal boot loader, to the operating system.
Of course, this may be the case for i.MX6, in fact there are a variety of different types of security booting, such as X86 with UEFI security boot, but for the sake of understanding this article focuses on i.MX6.
Use hardware
The i.MX6 hardware suite includes a number of special security mechanisms that are safe for startup, and the key to safe startup is the one-time fuse used to burn in the key. Once fused, it can no longer be connected As a result, the hash value is permanent once your key is burned in. Multiple keys can also be integrated into a single key hash, so a key can be revoked if it is compromised.
Another feature of system security is the internal boot loader, which is a piece of code that is also safely tested, which is an important foundation until the entire chain of the operating system remains safe.
In addition, the i.MX6 has a hardware cryptographic accelerator, and algorithms such as AES Hashing, Triple DES Hashing, SHA1 and SHA256 can all be accelerated via the i.MX6 processor, resulting in a dramatic increase in security processing.
Disadvantages
The obvious drawback is that you have to be responsible for your own security, and if your key is leaked to the outside world, someone will use the key stored in the processor to sign the code, so you have to ensure that the process and the hardware are safe.
In addition, a processor configured for safe boot purposes only starts after the image is properly signed, so any error in burning the hash into the processor can cause the processor to fail to execute the code, Because the hash value does not match - thus becoming a useless processor.
Once the processor is set up for safe execution, you must load a secure code that will only allow you to safely load it from storage (such as an SD card or NAND flash memory) or otherwise load the software Processor (USB image loading).
Therefore, hardware and processor preparation must be guaranteed, and you must also ensure that your boot loader is well prepared for this.
As mentioned earlier, your boot loader must call the secure boot library on the processor in order to authenticate the next stage of the boot chain. If you fail to properly code the boot loader for proper use of the secure library, you may not be able to Completely ensure the safety of the operating system.
Do not fall into the trap of false security
It is important to understand that i.MX6's secure startup does not lock the entire system but only the operating system software, so one might write some Linux malware that runs on the operating system and, if they are successfully loaded, will Harm the entire system.
i.MX6 safe start certification
If more complete security is required, you can also authenticate the rest of the file system and the code i.MX6 safe boot process principle is that a particular memory block has a specific cryptographic hash value and associated signature information so that it is possible Loading the operating system's root file system and other important files into a fixed location in the memory while loading the correct security instruction set allows you to authenticate the rest of the system when necessary.
i.MX6 safe start important tricks
1. Make sure the boot process is safe Once you've decided on a safe boot path, you have to make sure that the process goes hand-in-hand with the leak of the key in production.
2. Make sure that the strong encryption method ensures that the encryption method used is strong enough that the user is likely to establish a weaker key and the secure boot on i.MX6 also supports older or now compromised compromises Therefore, make sure your algorithm is up-to-date and able to meet your goals.
3. Check Your Code For a safe startup, which means anything else, including starting the rest of the code in the loader, the operating system and other software must be written correctly on a safe boot with no security flaws.
In addition, each phase of the boot process must be checked for next steps before it is executed, and if this is not done, or if it is done in part, the scope of what can be called process safety will be much smaller.
4. Authenticate Everyplace For real security, try to authenticate as much of the code as you want and ensure that you follow the instructions for building your library.
You have to make sure that the entire process is safe, that is, how to generate and store your key. Safe boot only checks the signature, and any signed image is considered safe by the processor.
So, make sure that every single piece of code you write is invoked on the processor's secure boot library to continue authenticating your mirror because most i.MX6 boards have multiple stages During the boot process, the internal boot loader of the CPU loads the SPL first, and then the SPL then loads the complete boot loader for loading into the operating system. Each step must be certified in the previous step to confirm that it is safe.
5. Verify that the process is validated to make sure that the code actually performs a safe startup. It is important that even secure code can jump anywhere in memory because the processor works like this. It is important to actually ensure that the code will authenticate the next step.
The most commonly used boot loader for i.MX6 is U-Boot, which really supports secure boot on i.MX6. It needs to be configured, but it's simpler. When a lot of work has been done, you There should be fewer mistakes. Writing security from scratch is not a good idea, but it is best to take a known, ideal approach to building and adapt it to your design needs.