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

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

针对PKCS#1 v2.0(RSA-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

用户什么情况下回等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证书的方式；多个证书需要更多经费