安全世界的理念是让执行的代码尽可能的小和简单——完成其职责的最低限度(通常控制对加密密钥或硬件等资源的访问,或促进加密/解密等安全功能) .
由于安全世界中的代码量很小,因此可以轻松对其进行审核,并且减少了引入错误的表面积。然而,这并不意味着安全的世界会自动“安全”。如果安全世界代码中存在漏洞,它可以像任何其他安全漏洞一样被利用。
将此与在正常世界中执行的代码进行对比。例如,Linux 内核要复杂得多,也更难审计。有很多内核漏洞和漏洞利用示例允许恶意代码接管内核。
为了说明这一点,让我们假设您有一个系统,用户可以通过一些质询-响应交易系统付款。当他们想要进行交易时,设备必须等待用户按下物理按钮,然后才能使用加密密钥签署交易并授权支付。
但是如果一些恶意代码利用了内核漏洞并且能够在内核模式下运行任意代码呢?通常这意味着彻底失败。该恶意软件能够绕过所有控制机制并读出签名密钥。现在,恶意软件可以向任何它想要的人付款,甚至不需要用户按下按钮。
如果有一种方法允许在 Linux 内核不知道实际密钥的情况下签署交易怎么办?进入安全世界系统。
我们可以拥有一个小型安全世界操作系统,其唯一目的是签署交易并持有签名密钥。但是,除非用户按下特殊按钮,否则它将拒绝签署交易。这是一个非常小的操作系统(以千字节为单位),并且您已聘请人员对其进行审核。出于所有意图和目的,安全世界操作系统中没有错误或安全漏洞。
当普通世界操作系统(例如 Linux)需要签署一个交易时,它会调用 SMC 将控制权转移到安全世界(注意,普通世界根本不允许修改/读取安全世界)与它的交易想签名。安全世界操作系统将等待用户按下按钮,签署交易,然后将控制权转移回正常世界。
现在,想象一下恶意软件接管 Linux 内核的情况。恶意软件现在无法读取签名密钥,因为它位于安全世界中。未经用户同意,恶意软件无法签署交易,因为除非用户按下按钮,否则安全世界操作系统将拒绝签署交易。
这种用例就是安全世界的设计目的。整个想法是安全世界和正常世界之间的硬件强制分离。在正常世界中,没有办法直接篡改安全世界,因为硬件可以保证这一点。
我没有特别与 TrustZone 合作过,但我想一旦安全世界操作系统启动,就无法直接修改它。我不认为应用程序开发人员应该能够向安全世界操作系统“添加”服务,因为这会违背它的目的。我还没有看到任何供应商允许第三方将代码添加到他们的安全世界操作系统中。
为了回答你的最后一个问题,我已经在这里回答了。SMC 例外是您从安全世界操作系统请求服务的方式——它们基本上是系统调用,但用于安全世界操作系统。恶意代码通过将控制权转移到安全世界会获得什么?
- 您无法从正常世界修改/读取安全世界
- 当您将控制权转移到安全世界时,您会在正常世界中失去控制权