secure boot 的知识
来源:互联网 发布:scala二维数组 编辑:程序博客网 时间:2024/05/18 01:51
ARM TrustZone 使用这种boot方式。
1. 什么是 secure boot?
5.2.2. Secure boot
A secure boot scheme adds cryptographic checks to each stage of the Secure world boot process. This process aims to assert the integrity of all of the Secure world software images that are executed, preventing any unauthorized or maliciously modified software from running.
Cryptographic signature protocol
The most logical cryptographic protocol to apply is onebased on a public-key signature algorithm, such as RSA-PSS (Rivest, Shamir and Adleman - Probabilistic Signature Scheme).
In these protocols a trusted vendor uses their Private Key (PrK) to generate a signature of the code that they want to deploy, and pushes this to the device alongside the software binary. The device contains the Public Key (PuK) of the vendor, which can be used to verify that the binary has not been modified and that it was provided by the trusted vendor in question.
The PuK does not need to be kept confidential, but it does need to be stored within the device in a manner which means it cannot be replaced by a PuK that belongs to an attacker.
Chain of trust
The secure boot process implements a chain of trust.Starting with an implicitly trusted component, every other component can be authenticated before being executed. The ownership of the chain can change at each stage - a PuK belonging to the device OEM might be used to authenticate the first bootloader, but the Secure world OS binary might include a secondary PuK that is used to authenticate the applications that it loads.
Unless a design can discount hardware shack attacks the foundations of the secure boot process, known asthe root of trust, must be located in the on-SoC ROM. The SoC ROM is the only component in the system that cannot be trivially modified or replaced by simple reprogramming attacks.
Storage of the PuK for the root of trust can be problematic; embedding it in the on-SoC ROM implies that all devices use the same PuK. This makes them vulnerable to class-break attacks if the PrK is stolen or successfully reverse-engineered. On-SoC One-Time-Programmable (OTP) hardware, such as poly-silicon fuses, can be used to store unique values in each SoC during device manufacture. This enables a number of different PuK values to be stored in a single class of devices, reducing risk of class break attacks.
Note
OTP memory can consume considerable silicon area, so the number of bits are that available is typically limited. A RSA PuK is over 1024-bits long, which is typically too large to fit in the available OTP storage. However, as the PuK is not confidential it can be stored in off-SoC storage, provided that a cryptographic hash of the PuK is stored on-SoC in the OTP. The hash is much smaller than the PuK itself (256-bits for a SHA256 hash), and can be used to authenticate the value of the PuK at run-time.
On-SoC Secure world or Off-SoC Secure world
The simplest defense against shack attacks is to keep any Secure world resource execution located in on-SoC memory locations. If the code and data is never exposed outside of the SoC package it becomes significantly more difficult to snoop or modify data values; a physical attack on the SoC package is much harder than connecting a logic probe to a PCB track or a package pin.
The secure boot code is generally responsible for loading code into the on-SoC memory, and it is critical to correctly order the authentication to avoid introducing a window of opportunity for an attacker. Assuming the running code and required cryptographic hashes are already in safe on-SoC memory, the binary or PuK being verified should be copied to a secure location before being authenticated using cryptographic methods. A design that authenticates an image, and then copies it into the safe memory location risks attack. The attacker can modify the image in the short window between the check completing and the copy taking place.
- secure boot 的知识
- UEFI、BIOS、Secure Boot的关系和知识介绍
- UEFI、BIOS、Secure Boot的关系和知识介绍
- Secure Boot
- Secure Boot功能介绍
- secure boot原理
- secure boot-dm verify
- EFI secure boot
- 关于Y400安装ubuntu的secure boot问题
- 如何在 Linux 系统启用 UEFI 的 Secure Boot
- Android安全框架:Verfied boot -- Secure Boot
- spring-boot入门需要了解的知识
- Linux Foundation Secure Boot System Released
- Exploiting samsung galaxy s4 secure boot
- MTK Secure Boot使用过程总结
- 高通Secure Boot调试流程记录
- 高通Secure Boot调试流程记录
- Secure CRT的实用技巧
- Python:类型
- 18. 4Sum
- opencv(9)---图像基本操作
- mysql导入数据时提示 USING BTREE 错误解决办法
- 《算法导论》第4章 分治策略 个人笔记
- secure boot 的知识
- [编程题] 度度熊回家
- 【Android】判断应用Application、Activity、Service是否处于活动状态
- 二分贪心 U题
- Tensorflow学习:单层神经网络的建立
- cipher加密解密
- HDOJ 2011 多项式求和
- hdu5391Zball in Tina Town(素数鉴别的大猜想)
- 本blog停更,以后将使用个人blog站点:www.haibusuanyun.com