Difference between revisions of "Bleichenbacher Attack"
| Line 2: | Line 2: | ||
The popular RSA asymmetric encryption has a deterministic nature. Therefore PKCS was added to RSA which uses padding to remove the deterministic and add two functionalities. This two are the signature and the encryption of packets and each of those are indicated at the second MSB. Following is a picture of a valid PKCS 1.5 packet: | The popular RSA asymmetric encryption has a deterministic nature. Therefore PKCS was added to RSA which uses padding to remove the deterministic and add two functionalities. This two are the signature and the encryption of packets and each of those are indicated at the second MSB. Following is a picture of a valid PKCS 1.5 packet: | ||
[[File:pkcs-paket.png]] | [[File:pkcs-paket.png]] | ||
In this picture you see a 0 Byte as MSB followed by a "2" to indicate encryption. Following is the variable padding with at least 8 Byte, delimited from another 0 Byte. | In this picture you see a 0 Byte as MSB followed by a "2" to indicate encryption. Following is the variable padding with at least 8 Byte, delimited from another 0 Byte. | ||
Revision as of 19:38, 21 December 2020
Description
The popular RSA asymmetric encryption has a deterministic nature. Therefore PKCS was added to RSA which uses padding to remove the deterministic and add two functionalities. This two are the signature and the encryption of packets and each of those are indicated at the second MSB. Following is a picture of a valid PKCS 1.5 packet:
In this picture you see a 0 Byte as MSB followed by a "2" to indicate encryption. Following is the variable padding with at least 8 Byte, delimited from another 0 Byte.
Requirements
There are a couple things which are needed for an effective Bleichenbacher Attack. Basically this attack works with RSA PKCS 1.5 but there is one important requirement: a Bleichenbacher Oracle. Such an oracle is a target system which answers repeated questions concerning the validity of an PKCS paket. To create such an oracle there are basically three ways:
- Plain Envryption: if implementation is without signature, the target system will only check the validity of the PKCS paket and sending an error message if the paket is invalid
- Detailed Error Messages: if encryption and signature is applied, but the target system generates specific eroors regarding the validity of an pkcs paket
- Timing Attack: if encryption and signature is applied in a proper way, you can still check the time between responses to generate a side channel regarding the validity of the paket
Affected Products
There are many implementations that are vulnerable. The product list includes:
- F5
- Citrix
- Cisco
- Java / JSSE
- IBM GSKit
- Bouncy Castle
- SSL 1.0 - 1.3
- TLS 1.0 - 1.2
Implementations in TLS 1.1 and 1.2 may not be practicably vulnerable if implemented with the attack in mind. Due to the complexity of an correct implementation, this easily can be done wrong and there's still a side channel to generate an oracle. With TLS 1.3 PKCS key exchange is fully dropped regarding the encryption.