G.O.S.S.I.P 阅读推荐 2022-06-23

小编从未见过如此“厚颜无耻”的作者，声称“Although our specific attacks only apply to the ≈100 million devices made by Samsung, it raises the much more general requirement for open and proven standards for critical cryptographic and security designs.” 把如此严重的问题故意使用”欲扬先抑“的修辞手法来描述，这是什么研究工作呢？请看今天的论文推荐——来自USENIX Security 2022的 Trust Dies in Darkness: Shedding Light on Samsung’s TrustZone Keymaster Design

来自以色列特拉维夫大学的研究人员逆向分析了三星在自家TrustZone中的密码学核心进程——Keymaster的主要逻辑实现，然后提出了一种针对Keymaster使用的AES-GCM加密模式的IV reuse attack，同时还发展了一类downgrade attack，使得即使最新的三星旗舰系列Android设备也可以引入这种IV reuse attack，影响了从S8开始直到S20、S21系列的设备

先回忆一下密码学课程上老师教给你的知识，AES-GCM模式本质上是一种AES-CTR模式，其安全性高度依赖于使用的nonce（也就是本文中关注的IV）是否每次都随机生成，如果nonce被重用，在使用相同的key时，就会产生相同的pseudo random stream，然后面临类似流密码算法密钥重用的一系列攻击。

在今天（2020年之后）的几乎所有主流Android设备上都已经配置了使用TrustZone保护的密码学运算（Keystore服务），保证关键的密钥仅在TrustZone里面使用，即使外部操作系统被攻击，敌手也无法拿到主要的密钥。

在这种安全性保证下，继而构建起来一系列外围的服务，例如可以在OS层面保存很多敏感数据，其解密则只能通过调用TrustZone内部的Keymaster（这时候往往触发指纹认证，如下图的Secure Monitor的）来实现。

在密码学世界里面，通常我们不会使用最关键的那一把钥匙——master key（好像有点反动，我们是不是不应该使用master/slave这种政治不正确的词汇），而是在每次会话时候基于核心密钥推导出一些临时密钥来使用。这些临时密钥可以通过所谓的KEK（也就是Key Encryption Key）来保护。实际上在TrustZone里面密钥管理相当复杂，核心一般是所谓的Root Encryption Key（REK，甚至TA都无法直接访问到），然后派生出各类Hardware Derived Key（HDK），然后再用HDK去保护在normal world里面存储的密钥（这种加密后存储在normal world的敏感数据称之为key blob）。在现实中，三星部署了如下三个版本的HDK密钥推导方法：

接下来就是问题所在：在这几个版本的HDK密钥推导中，前面两个方法生成的密钥只和使用keymaster服务的app id相关，也就是说，如果一个特定的app去请求keymaster为其产生多个key blob，这些key blob都是用完全一样的HDK保护的，而保护的方法又恰好是AES-GCM，也就是说，如果这时候使用的IV再相同，就完全满足我们前面介绍的针对AES-CTR模式的攻击前提了！

遗憾的是，在三星的设计中，keymaster对normal world提供的接口允许外界直接指定IV，假设攻击者控制了外部OS，就可以反复使用同一个IV（而keymaster基本上是不会去检查这个reuse情况的），这样安全攻击就发生了！攻击者只要想办法去弄到某一个key blob的key明文（最好让这个key足够长），然后利用这个key blob的明文和密文作为一个解密机，可以恢复其他任意key blob中保护的key！

更有意思的是，也许是为了保证兼容性，即使设备部署了最新的（第三种）HDK推导方案，攻击者在控制OS的情况下，仍然可以通过强行传入特定的参数，迫使keymaster产生旧版本的key blob（诶呀妈呀产品经理又要背锅了）！

下面我们来看看实际的攻击，如果你读过NDSS 2018年那篇Broken Fingers: On the Usage of the Fingerprint API in Android（没读过就赶紧去读！https://reyammer.io/publications/2018_ndss_fingerprint.pdf）就应该很熟悉下面这幅图所示的key import应用场景。在NDSS 2018的论文中，作者指出了在使用指纹时种种不安全的实现，并强调严格按照规范去实现key import才能保证安全。可在本文的场景下，即使我们严格遵循了标准的流程，还是会存在问题！主要原因在于攻击者可以利用IV reuse attack把key blob里面的内容恢复出来，这样整套key import协议的安全性就荡然无存了。

由于这种解密key blob的能力太强，连FIDO标准都中招了（当然这时候我们不能怪FIDO的协议不安全）

不知道你读完这篇论文觉不觉得过瘾，小编我反正觉得这篇论文读起来非常有意思，并且已经将目光盯上了其它一些Keymaster实现了~

论文PDF：

https://www.usenix.org/system/files/sec22fall_shakevsky.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-06-23