S5542 — Encryption algorithms should be used with secure mode and padding scheme

Language
VB.NET
Type
Vulnerability
Severity
Critical
Tags
cryptography, cwe, privacy

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

  1. No encryption is unbreakable.
  2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

For AES, the weakest mode is ECB (Electronic Codebook). Repeated blocks of data are encrypted to the same value, making them easy to identify and reducing the difficulty of recovering the original cleartext.

For RSA, the weakest algorithms are either using it without padding or using the PKCS1v1.5 padding scheme.

For RSA signatures, the generally recommended good practice is to use RSASSA-PSS.

What is the potential impact?

The cleartext of an encrypted message might be recoverable, modifiable, or a signature might be forged.

Below are some real-world scenarios that illustrate possible impacts of an attacker exploiting the vulnerability.

Theft of sensitive data

The encrypted message might contain data that is considered sensitive and should not be known to third parties.

By using a weak algorithm the likelihood that an attacker might be able to recover the cleartext drastically increases.

Additional attack surface

By modifying the cleartext of the encrypted message it might be possible for an attacker to trigger other vulnerabilities in the code. Encrypted values are often considered trusted, since under normal circumstances it would not be possible for a third party to modify them.

Forged signatures

A weak signature padding scheme without a security proof might allow an attacker to forge a signature that a flawed verifier implementation accepts as valid, undermining the trust and integrity guarantees signatures are meant to provide.

How to fix it in .NET

Code examples

Noncompliant code example

Example with a symmetric cipher, AES:


Imports System.Security.Cryptography

Public Module Example

    Public Sub Encrypt()
        Dim Algorithm As New AesManaged() With {
            .KeySize = 128,
            .BlockSize = 128,
            .Mode = CipherMode.ECB, ' Noncompliant
            .Padding = PaddingMode.PKCS7
            }
    End Sub
End Module

Example with an asymmetric cipher, RSA:


Imports System.Security.Cryptography

Public Module Example

    Public Sub Encrypt()
        Dim data(10) As Byte
        Dim RsaCsp = New RSACryptoServiceProvider()
        RsaCsp.Encrypt(data, False) ' Noncompliant
    End Sub
End Module

Examples with an RSA signature scheme:


Imports System.Security.Cryptography

Public Module Example

    Public Function Sign(dataToSign As Byte()) As Byte()
        Using rsa As New RSACng()
            Return rsa.SignData(dataToSign, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1) ' Noncompliant
        End Using
    End Function
End Module


Imports System.Security.Cryptography

Public Module Example

    Public Function Sign(dataToSign As Byte()) As Byte()
        Using rsa As RSA = RSA.Create()
            Return rsa.SignData(dataToSign, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1) ' Noncompliant
        End Using
    End Function
End Module

Compliant solution

For the AES symmetric cipher, use the GCM mode:


Imports System.Security.Cryptography

Public Module Example

    Public Sub Encrypt()
        Dim data(10) As Byte
        Dim Algorithm As New AesGcm(data)
    End Sub
End Module

For the RSA asymmetric cipher, use the Optimal Asymmetric Encryption Padding (OAEP):


Imports System.Security.Cryptography

Public Module Example

    Public Sub Encrypt()
        Dim data(10) As Byte
        Dim RsaCsp = New RSACryptoServiceProvider()
        RsaCsp.Encrypt(data, True) ' Noncompliant
    End Sub
End Module

For RSA signatures, use the Probabilistic Signature Scheme (RSASSA-PSS). RSACng supports it on both .NET Framework and modern .NET:


Imports System.Security.Cryptography

Public Module Example

    Public Function Sign(dataToSign As Byte()) As Byte()
        Using rsa As New RSACng()
            Return rsa.SignData(dataToSign, HashAlgorithmName.SHA256, RSASignaturePadding.Pss)
        End Using
    End Function
End Module


Imports System.Security.Cryptography

Public Module Example

    Public Function Sign(dataToSign As Byte()) As Byte()
        ' On .NET Framework, replace RSA.Create() with New RSACng()
        Using rsa As RSA = RSA.Create()
            Return rsa.SignData(dataToSign, HashAlgorithmName.SHA256, RSASignaturePadding.Pss)
        End Using
    End Function
End Module

How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

Appropriate choices are currently the following.

For AES: use authenticated encryption modes

The best-known authenticated encryption mode for AES is Galois/Counter mode (GCM).

GCM mode combines encryption with authentication and integrity checks using a cryptographic hash function and provides both confidentiality and authenticity of data.

Other similar modes are:

For RSA: use the OAEP scheme

The Optimal Asymmetric Encryption Padding scheme (OAEP) adds randomness and a secure hash function that strengthens the regular inner workings of RSA.

For RSA signatures: use the RSASSA-PSS scheme

The Probabilistic Signature Scheme (RSASSA-PSS) uses a randomized encoding and comes with a security proof, whereas the older PKCS#1 v1.5 signature scheme (RSASSA-PKCS1-v1_5) has none and has repeatedly enabled signature forgery against flawed verifier implementations.

IETF RFC 8017 therefore requires RSASSA-PSS for new applications, in the interest of increased robustness.

Pitfalls

RSA.Create() is not guaranteed to return a type that supports RSASSA-PSS. On .NET Framework, it resolves to RSACryptoServiceProvider, whose SignData/SignHash throw a CryptographicException when called with RSASignaturePadding.Pss. Use RSACng explicitly when the code must run on .NET Framework.

Resources

Articles & blog posts

Standards

↑ Back to top