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

admin 2022年6月24日04:37:20安全闲碎评论5 views2338字阅读7分47秒阅读模式

小编从未见过如此“厚颜无耻”的作者,声称“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

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

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

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

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

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

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

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

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

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


在密码学世界里面,通常我们不会使用最关键的那一把钥匙——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密钥推导方法:


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


接下来就是问题所在:在这几个版本的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!

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

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

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

下面我们来看看实际的攻击,如果你读过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协议的安全性就荡然无存了。

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

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

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

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

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


论文PDF:

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


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

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年6月24日04:37:20
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  G.O.S.S.I.P 阅读推荐 2022-06-23 http://cn-sec.com/archives/1138878.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: