@1qaz 2016-05-16T22:08:56.000000Z 字数 2454 阅读 1076

Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS

Timing Attack TLS

Martin R. Albrecht and Kenneth G. Paterson,Royal Holloway, University of London, eurocrypt 2016 原文

一句话：Amazon的TLS实现s2n，修补Lucky 13不完全导致的计时攻击

1. Introduction

s2n依赖OpenSSL底层的crypto操作,用较少的、清晰的代码来实现TLS协议。作者指出s2n实现的CBC模式，两种抵御Lucky 13攻击的方法是不完全的
(1) 用额外的操作使得解密时正确和错误padding处理时间相同
(2) MAC错误时引入随机的延时

方法(1)对payload和所有的padding都做HMAC。使用s2n_hmac_update，但是对相同长度的输入，不能保证hash的压缩函数被调用的次数相同
方法(2)使用sleep和usleep，用毫秒级的延迟掩盖错误的padding产生的时间差。但时间差的source不均匀uniform

OpenSSL修补Lucky 13用500行代码, constant time/constant memory access ,在协议层直接使用底层的hash压缩函数而不是HMAC接口。 s2n出于分层的考虑，使用不同的策略

对方法(1)的攻击利用了s2n计数HMAC输入的字节，而不是hash压缩函数次数。漏洞披露后，s2n改为计数压缩函数次数，usleep改为nanosleep

2. TLS Record Protocol and s2n

TLS:Mac-Then-Enc
CBC

|-SEQ && HDR-||-Payload-|
|  8   +   5  |   n     |
_________________________
              |_____HMAC______
                              |
              | Payload || MAC tag | Padding | 
              _______________________________
                             ENC|
        | HDR |-------------------------------|

Padding格式是p+1个值为p的字节。Lucky13中利用padding最后字节被修改导致解析后的payload长度不同，进而HMAC hash耗时不同

HMAC
HMAC = H( (K xor opad) || H( (K xor ipad)||M ) )
opad、ipad长度为64字节
MD5、SHA1、SHA256要先将长度填充到 56 mod 64，填充长度至少为1个字节。所以输入长度mod64 >= 56就会填充一个block

例如，M长55字节，H（(K xor ipad)||M )需要两次hash压缩，外层也是两次，整个HMAC要4次压缩；若M长56字节，内层3次压缩，外层2层，总共5次。
一次压缩大概几百个时钟周期

hash实现时通常是3个接口，init、update、final，update在输入缓冲不满一个block时不会调用hash压缩，final最多调用2次压缩

s2n解密时HMAC的处理：读最后一个字节，确定padding长度，除去尾部的mac tag和padding，得到payload，计算SEQ||HDR||payload的MAC tag，与解密出的mac tag比较(const time),无论比较结果，之前的MAC状态update padding，舍弃结果（代码）

random delay

sleep(delay/1000000)
usleep(delay%1000000）
delay between 1,000 and 10,001,000

3. Attack w/o Random Waiting Countermeasure

HMAC-SHA256
C(delta) = HDR || C₀ ||C₁ || C₂ ||C₃ ||C' xor delta || C*
C₀是IV，C*原来的明文是P*
P₅ = P* xor delta

payload+padding = 16*5 -32 = 48
Case 1:P₅结尾字节是{0x00,...,0x04},padding_length最多为4，payload_length最少为48-4-1 = 43，最多为47，HMAC输入长至少为13+43 = 56,5次压缩。mac比较完后，继续update padding，padding最多4字节，buffer不到64字节（正好为60字节，13+48-1 = 60，与填充长度无关），在最后update时并不会压缩

Case 2:P₅结尾字节是{0x05,...,0xff},payload_length最多为48-5-1=42,，HMAC输入最多13+42=55,4次压缩。update padding之后buffer也是60字节，并不会压缩

改变delta的高6位比特，如果耗时相对较长，P* xor delta 低2位比特在{0x00,...,0x04}中；再修改低3位比特，就恢复出一个字节？？？

4. Defeating the Random Wait Countermeasure

大部分情况下(9/10) sleep(0) 不超过250个时钟周期
usleep 粒度是1μs，3.3GHz 1μs 3300 clock cycle，取模得余数，就可以过滤掉usleep带来的噪音？

usleep只保证至少sleep 那么多μs

区分攻击:根据不同的延时来判断P* xor delta在{0x00,...,0x04}中还是在{0x05,...,0xff}中

两个概率分布之间尽可能大
。。。

5. POC

padding length values 0x00-0xFF,比较运行时间
attack with delay

6. Conclusion

hmac_update 不一定调用hash compression，hmac_digest才会
即使max delay足够大，delay的不均匀分布也可被利用。nanosleep足够均匀
Mac-Then-Encrypt should be avoided.

s2n patch