\begingroup

直到最近,我列出的可能导致侧通道从计算机中运行的代码中泄露秘密数据(包括依赖于秘密的数据)的原因仅限于:

  1. 硬件排放:电源(例如 SPA)、电磁(例如 DEMA、Tx/Rx LED、[更新])、声音(例如来自电源)
  2. 恶意访问内存/媒体:例如通过内核代码、缓冲区溢出、内存管理的副作用、JTAG 接口、DMA、冷启动、微探测或更普遍的绕过访问限制。我将任何通信接口的渗透都归入此类别。
  3. 具有数据相关时序的指令可能由于时序变化而导致泄漏:例如乘法,请参阅
  4. 根据机密(if、switch..)进行代码分支,可能因时序变化或其他方式(如共享分支预测逻辑)导致泄漏。我将根据条件代码进行条件执行(不进行分支)归入此类,因为这样会导致泄漏。
  5. 内存读取或写入与秘密相关的内存位置(例如,在与密钥相关的地址处读取表),这可能会因时序变化或其他方式(例如共享缓存)而导致泄漏。

现在我们必须在某些(Apple)CPU 中添加依赖于数据内存的预取器:

DMP 激活(并尝试取消引用)从内存中加载的“看起来像”指针的数据。

因此,现在内存中读取的数据值可能会因计时或其他方式(如共享缓存,而不是硬件排放)而导致泄漏!!有关详细信息,请参阅 Boru Chen、Yingchen Wang、Pradyumna Shome、Christopher W. Fletcher、David Kohlbrenner、Riccardo Paccagnella 和 Daniel Genkin:

问题:写入内存的数据值是否也会导致某些常见 CPU 出现泄漏?我特别想到当内存子系统中的某些小装置注意到正在写入的值与在该位置读取的最后一个值相同时,抑制内存写入。

常见计算机设备(台式机、服务器、大型机、便携式、移动式、嵌入式 CPU、GPU……)上经常进行加密的侧通道是否存在其他已知原因而我没有讨论过?

\endgroup

3

  • 1
    \begingroup
    我认为“根据秘密进行代码分支”有一个类似的例子,例如,密码放在页面边界上,如果在从内存中检索页面之前或之后密码或 PIN 失效,内存时序就会泄漏。所以在这种情况下,CPU 并没有真正泄漏,但 MMU 会泄漏。还不足以回答,但可能可以发表评论 🙂
    \endgroup


    – 

  • \begingroup
    “现在,据报道我们必须在某些 (Apple) CPU 中添加依赖于数据内存的预取器” – 我认为 DMP 不仅限于 M 系列 CPU。只有这个特定的漏洞才是。显然,英特尔也使用 DMP,他们只是更严格地验证数据,以尝试确保“看起来像指针”的东西实际上一个指针,并且允许当前进程访问。
    \endgroup


    – 

  • \begingroup
    @JörgWMittag¨:我相信这一点;但从安全角度来看,需要验证的不仅是数据是否是进程的有效指针;而且当前进程实际上将按照预取程序假定的方式使用这个指针!
    \endgroup


    – 


最佳答案
3

\begingroup

问题:写入内存的数据值是否也会导致某些常见 CPU 出现泄漏?我特别想到当内存子系统中的某些小装置注意到写入的值与在该位置读取的最后一个值相同时,抑制内存写入。

是的。几年前,英特尔 CPU 就实现了零对零冗余存储消除,这在某些情况下会对性能产生可衡量的影响,即侧信道泄漏。例如:

  • Travis Downs,《》,Performance Matters 博客,2020 年 5 月 13 日(
  • Travis Downs,《》,Performance Matters 博客,2020-05-18(

英特尔似乎已经在微代码更新中禁用它,但很难知道这是否可靠:

  • Travis Downs,“”,Performance Matters 博客,2021-06-17(

\endgroup

2

  • 1
    \begingroup
    所以“商店消除”是可行的!这让我感到欣慰,速度是安全的敌人,而安全的做法是假设如果对手可以在处理机密的同一台机器上运行,那么这些机密就很容易受到攻击。
    \endgroup


    – 


  • 1
    \begingroup
    @fgrieu:更具体地说,如果它们可以同时运行。如果运行时环境(虚拟机管理程序、操作系统)在任务切换之间刷新缓存并确保不同安全主体的代码不会同时运行,则大多数定时侧通道将被阻止。这些都是非常短暂的。
    \endgroup


    – 

\begingroup

因此现在内存中读取的数据值可能会导致泄漏

这并不是什么新鲜事。随着也引起了人们的关注。瞬时执行漏洞的基本原理是,代码会以泄露的方式使用敏感值,但该代码受到错误条件的保护。攻击者试图安排代码以推测方式执行,例如通过启动分支预测器。由于条件为假,敏感值实际上并没有以可直接观察到的方式使用。但执行会通过侧通道泄露信息。

例如,考虑以下伪代码,其中secret是一个变量,其值是敏感的,并且false_condition()根据软件构造为假:

if false_condition():
    f(array[secret])

处理器不知道是false_condition()假的,所以它可能会推测性地获取array[secret],这会导致缓存负载泄漏的值secret

是推测执行可能读取不该读取的内容的另一种方式。x86处理器上的存在弱点,其中一个处理器线程可能会推测性地开始处理实际上属于另一个线程的值。几个周期后,处理器注意到线程正在混合并取消推测执行,但这可能有一个可观察到的侧信道。这符合上述模式,只是这里的false_condition()不是软件,而是处理器内部的检查,可以符号写为thread_of_instruction == thread_of_value

写入内存的数据值在某些常见的CPU上是否也会造成泄漏?

可以,至少通过软件可以。Linux 支持。此功能适用于运行许多分区且软件大多相同的虚拟机管理程序。启用此功能后,虚拟机管理程序会扫描内存以查找相同的页面。当它发现两个具有相同内容的物理页面 P1 和 P2 时,指向 P2 的 MMU 表将更新为指向 P1,并且释放 P2。这允许攻击者进行 oracle 攻击:给定一个具有大部分已知内容的受害页面,攻击者用可能的内容填充页面,等待重复数据删除器。根据后续修改的时间,攻击者可以确定页面是否已被重复数据删除,即它是否与受害页面相同。


这些攻击的共同点是,与针对加密实现的“经典”计时攻击不同,它们不直接涉及加密代码。决定你的加密秘密是否泄露的不是操纵它们的代码,而是操作系统中的其他代码。

\endgroup

1

  • 1
    \begingroup
    很多很棒的作品!进一步的论据是,将秘密锁定在为此设计的 CPU 中才是可行的方法。
    \endgroup


    – 


\begingroup

假设我对某个系统有物理访问权限,即:我可以接近它,我注意到有两件事“泄露”了信息,它们都与 EMI 有关。

  1. SRAM侦听

SRAM 传输线终止于“噪声”;但是,如果您决定使用 SRAM 频率的基频来激励电路板,您将可以看到数据在网络矢量分析仪上改变发射频谱。我从未尝试过实际提取数据,但我相信您可以做到这一点,因为我们的 VA 是 60GHz。我们在实验室中注意到这是 RF 污染,所以我们只是移动东西,直到您看不到它。我可以详细描述攻击是如何进行的,但总结是,您拥有专门设计不会造成发射的传输线;但是,由于 E&M 定律,您可以用电“震动”它们以产生发射。

  1. 一切窥探

量子磁力计让我能够看到磁场中的磁扰动。你可以在 10,000 米处探测到潜艇,这与在 0.1 米处探测到 IC 磁场因电荷而发生的变化非常相似。我用 Quspin 磁力计获取了一些数据来查看电路噪声;但是,除了弄清楚传感器的放置位置之外,我从未深入研究过将数据与任何东西关联起来。

通过密码学家/RF 小组和密码学/量子传感器小组之间的合作,可以轻松探索这两者。在密码学家/RF 的情况下,我相信您能够提取一些东西,因为您看到的“噪音”不是随机的,这意味着它与某些东西相关。

\endgroup

3

  • \begingroup
    我会将这种窥探归类为“1. 硬件辐射”电磁子类别。但需要强调的是,使用量子传感器进行窥探目前对密码学来说是一个非常现实的量子威胁。
    \endgroup


    – 


  • 1
    \begingroup
    @fgrieu 在量子传感器案例中,你需要知道你在寻找什么。我之所以将它们分开,是因为一个是 RF,另一个是纯磁性的
    \endgroup


    – 


  • \begingroup
    如果您可以物理访问系统,从安全角度来看,通常可以假设您只需取出 CPU 并将其替换为恶意 CPU,因此防御工作最好是阻止人们物理访问您的系统,而不是在他们访问后尝试防御。尽管如此,这对某些人来说仍然很有趣。
    \endgroup


    –