[关闭]
@1qaz 2016-05-16T14:08:56.000000Z 字数 2454 阅读 786

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

  1. |-SEQ && HDR-||-Payload-|
  2. | 8 + 5 | n |
  3. _________________________
  4. |_____HMAC______
  5. |
  6. | Payload || MAC tag | Padding |
  7. _______________________________
  8. ENC|
  9. | 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 || C0 ||C1 || C2 ||C3 ||C' xor delta || C*
C0是IV,C*原来的明文是P*
P5 = P* xor delta

payload+padding = 16*5 -32 = 48
Case 1:P5结尾字节是{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:P5结尾字节是{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

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

6. Conclusion

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

s2n patch

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注