Verwendung eines kryptographischen Primitivs mit riskanter Implementierung

Beschreibung

Verwendung eines kryptographischen Primitivs mit riskanter Implementierung tritt auf, wenn ein Produkt einen kryptographischen Algorithmus mit einer nicht standardmäßigen, unerprobten oder nicht zugelassenen/nicht konformen Implementierung realisiert. Kryptographische Primitive müssen mathematisch zuverlässig und umfassend von Kryptographen erforscht sein. Wenn Schwächen in Primitiven entdeckt werden, werden ganze davon abhängige Systeme verwundbar. Eigene Implementierungen sind besonders riskant -- wenn Ad-hoc-kryptographische Primitive implementiert werden, ist es nahezu sicher, dass die Implementierung für Angriffe anfällig ist, die von Kryptographen gut verstanden werden. Hardware-Implementierungen bergen zusätzliche Risiken, da sie nach der Bereitstellung nicht gepatcht werden können.

Risiko

Riskante kryptographische Implementierungen haben schwerwiegende Sicherheitsauswirkungen. Verschlüsselung kann durch bekannte Angriffe brechbar sein. Zufallszahlengenerierung kann vorhersagbar sein. Schlüssel können aus Beobachtungen ableitbar sein. Seitenkanalangriffe können möglich sein. Mathematische Schwächen können ausgenutzt werden. Brute-Force-Angriffe können praktikabel werden. Compliance-Anforderungen können nicht erfüllt werden. Hardware-Schwachstellen können nicht gepatcht werden.

Lösung

Verwenden Sie etablierte kryptographische Bibliotheken und Implementierungen. Folgen Sie Standards wie NIST FIPS 140-3 für Anforderungen an kryptographische Module. Verwenden Sie NIST-zugelassene Algorithmen mit empfohlenen Schlüssellängen. Vermeiden Sie eigene oder Ad-hoc-kryptographische Implementierungen. Stellen Sie sicher, dass Zufallszahlengeneratoren kryptographisch sicher sind. Testen Sie Implementierungen gegen bekannte Angriffsvektoren. Berücksichtigen Sie Zukunftssicherheit gegen Quantenangriffe. Verwenden Sie Hardware-Sicherheitsmodule für sensible Operationen.

Häufige Auswirkungen

Auswirkung	Details
Vertraulichkeit	Bereich: Vertraulichkeit Anwendungsdaten lesen – Fehlerhafte Krypto-Verwendung könnte verschlüsselte Daten als unverschlüsselten Klartext darstellen. Hohe Ausnutzungswahrscheinlichkeit bei nicht standardmäßigen Implementierungen.

Beispielcode und Lösung

Verwundbarer Code

// VERWUNDBAR: LFSR anstelle eines echten TRNG für Schlüsselgenerierung

module vulnerable_key_generator (
    input wire clk,
    input wire reset_n,
    input wire generate_key,
    output reg [127:0] encryption_key,
    output reg key_ready
);

    // VERWUNDBAR: Linear Feedback Shift Register ist vorhersagbar!
    reg [31:0] lfsr_state;

    wire feedback = lfsr_state[31] ^ lfsr_state[21] ^ lfsr_state[1] ^ lfsr_state[0];

    always @(posedge clk or negedge reset_n) begin
        if (!reset_n) begin
            lfsr_state <= 32'hDEADBEEF;  // Fester Seed – noch schlimmer!
            encryption_key <= 128'h0;
            key_ready <= 1'b0;
        end
        else if (generate_key) begin
            // VERWUNDBAR: Angreifer kann alle zukünftigen Schlüssel vorhersagen
            lfsr_state <= {lfsr_state[30:0], feedback};
            encryption_key <= {encryption_key[95:0], lfsr_state};
        end
    end

endmodule

// VERWUNDBAR: Verwendung schwacher/veralteter Algorithmen

// VERWUNDBAR: DES mit 56-Bit-Schlüssel – per Brute-Force brechbar
void vulnerable_des_encrypt(uint8_t* data, uint8_t* key) {
    DES_key_schedule schedule;
    DES_set_key((DES_cblock*)key, &schedule);
    DES_ecb_encrypt((DES_cblock*)data, (DES_cblock*)data, &schedule, DES_ENCRYPT);
}

// VERWUNDBAR: MD5 für Passwort-Hashing – Kollisionsangriffe bekannt
void vulnerable_password_hash(const char* password, uint8_t* hash) {
    MD5_CTX ctx;
    MD5_Init(&ctx);
    MD5_Update(&ctx, password, strlen(password));
    MD5_Final(hash, &ctx);
}

Sichere Lösung

// SICHER: Verwendung korrekter kryptographischer Bibliotheken und Algorithmen

#include <openssl/evp.h>
#include <openssl/rand.h>

// SICHER: AES-256 mit korrekter Schlüssellänge
int secure_aes_encrypt(const uint8_t* plaintext, size_t len,
                       const uint8_t* key, const uint8_t* iv,
                       uint8_t* ciphertext) {
    EVP_CIPHER_CTX* ctx = EVP_CIPHER_CTX_new();

    // AES-256-GCM verwenden (authentifizierte Verschlüsselung)
    EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, key, iv);

    int out_len;
    EVP_EncryptUpdate(ctx, ciphertext, &out_len, plaintext, len);

    int final_len;
    EVP_EncryptFinal_ex(ctx, ciphertext + out_len, &final_len);

    EVP_CIPHER_CTX_free(ctx);
    return out_len + final_len;
}

// SICHER: Argon2 für Passwort-Hashing verwenden
#include <argon2.h>

int secure_password_hash(const char* password, uint8_t* hash) {
    uint8_t salt[16];
    RAND_bytes(salt, sizeof(salt));

    // Argon2id – speicherhart, resistent gegen GPU-Angriffe
    return argon2id_hash_raw(
        3, 1 << 16, 4,
        password, strlen(password),
        salt, sizeof(salt),
        hash, 32
    );
}

// SICHER: Kryptographisch sichere Zufallszahlengenerierung
int secure_generate_key(uint8_t* key, size_t len) {
    if (RAND_bytes(key, len) != 1) {
        return -1;
    }
    return 0;
}

---

CVE-Beispiele

• CVE-2020-4778: MD5-Verwendung anstelle von SHA-256
• CVE-2019-1543: ChaCha20-Poly1305 Nonce-Reduktion verletzt Cipher-Anforderungen
• CVE-2020-6616: Bluetooth-Chip verwendet Low-Entropy-PRNG anstelle von Hardware-RNG

---

Verwandte CWEs

• CWE-327: Use of a Broken or Risky Cryptographic Algorithm (übergeordnet)
• CWE-325: Missing Cryptographic Step (untergeordnet)
• CWE-338: Use of Cryptographically Weak PRNG (verwandt)

---

Referenzen

1. MITRE Corporation. "CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation." https://cwe.mitre.org/data/definitions/1240.html
2. NIST FIPS 140-3: Security Requirements for Cryptographic Modules
3. NIST CAVP (Cryptographic Algorithm Validation Program)