[关闭]
@1qaz 2015-10-29T13:58:16.000000Z 字数 1504 阅读 1101

On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption

未分类


TLS中RSA默认的填充方式是PKCS#1 v1.5,易受到旁路攻击(Bleichenbacher oracle)
TLS1.3 移除了PKCS#1 v1.5的支持,但这仍不足够避开pkcs#1 v1.5的弱点。由于老版本的存在,仍可被cross-protocol-version attack

background

RSA PKCS#1 v1.5

签名
h := H(M)
m := 0x01||0xFF||...||0xFF||0x00||ASN.1||h
消息M的签名即m^d mod N

加密
m := 0x00||0x02||PS||0x00||k

Bleichenbacher oracle & Manger oracle

bl-oracle
c = m^e mod N
c' = (c*s^e)mod N = (ms)^e mod N
输入c',oracle返回1时, 2*B≤ ms mod N < 3*B ,B=2^(8*(l-2))
不断选择新的s,可以减小m的范围,最后只剩一个值
对于1024bit的N,大约需要1 million oracle 查询来恢复明文

Manger's attack
ma-oracle
针对PKCS#1 v2.0(RSA-OAEP)
oaep
对于1024bit的N,大约需要1100次oracle 查询。
Bleichenbacher oracle 相比于 Manager oracle的不同在于manager每次查询会泄露m中大约1个比特的信息,但manager需要一个perfect oracle,没有false-positive/false-negative
RSA signing oracle

Attacks on TLS1.3

攻击流程
1. 客户端C发送TLS1.3 ClientHello,ClientKeyShare
2. 攻击者A截获信息,选择TLS-DHE-RSA,向C回答ServerHello,ServerKeyShare中包含了DH指数
3. A向服务端S发送ClientHello,S返回ServerHello和它的证书。A用该证书应答C
4. 为了完成TLS1.3 session的建立,A需要计算CertificatVerify,包含之前握手信息的签名。攻击者利用pkcs v1.5的oracle构造一个rsa签名
5. A和C完成握手后,就实现了中间人攻击

这个攻击是online的,在客户端没有发起ClientHello时,A是无法构造RSA签名的。攻击的可行性在于利用Oracle构造签名的时间要短于客户端断开连接的时间

Practical evaluation

server: TLS 1.2 TLS_RSA,TLS_DHE_RSA
client: only accept TLS_DHE_RSA
time1

time2
用户什么情况下回等30s来建立连接?
高延迟的公共WiFi,页面加载时用户在另一个tab上,。。。
有些TLS的场景是没有用户参与的,机器间的TLS通信,超时断开的时间要长的多(7700s)

Discussion

TLS各版本必须支持的套件
TLS 1.0: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS 1.1: TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS 1.2: TLS_RSA_WITH_AES_128_CBC_SHA
因此在现版本中禁止PKCS#1 v1.5是不可能的

x509证书并没有说明它应该被用在TLS什么版本什么密码套件中,应该被用于加密,还是用于签名(TLS_RSA,TLS_DHE_RSA);OpenSSL没有提供为不同TLS版本和密码套件使用不同RSA证书的方式;多个证书需要更多经费

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