Unsachgemäße Nullsetzung von Hardware-Registern

Beschreibung

Unsachgemäße Nullsetzung von Hardware-Registern tritt auf, wenn ein Hardware-Produkt sensible Informationen aus eingebauten Registern nicht ordnungsgemäß löscht, wenn der Benutzer des Hardware-Blocks wechselt. Hardware-IPs speichern Daten in lokalen Registern für E/A-Pufferung und Zwischenberechnungen. Sensible Daten wie Verschlüsselungsschlüssel oder Passwörter können in diesen Registern verbleiben. Wenn der Hardware-Zugriff den Besitzer wechselt, können neue Benutzer vorherige sensible Informationen extrahieren. Standards wie FIPS-140-2 betonen "Zeroization" -- das Löschen von Registerinhalten in kryptographischer Hardware.

Risiko

Unsachgemäße Register-Nullsetzung hat schwerwiegende Sicherheitsauswirkungen. Kryptographische Schlüssel können unautorisierten Benutzern offengelegt werden. Passwörter können aus Registern extrahiert werden. Zwischenberechnungswerte können Geheimnisse preisgeben. Vorherige Benutzerdaten können für neue Benutzer zugänglich sein. Sicherheitsgrenzen zwischen Benutzern können verletzt werden. Kryptographische Hardware kann Sicherheitszertifizierungen nicht bestehen. Datenrückstände können trotz Löschung bestehen bleiben. Seitenkanalangriffe können Restdaten ausnutzen.

Lösung

Definieren Sie klare Richtlinien für Register-Löschverfahren während der Architektur- und Designphase. Legen Sie die Verantwortung (Hardware oder Software) für die Initiierung der Nullsetzung fest. Löschen Sie sensible Register sofort nach Gebrauch. Implementieren Sie automatische Nullsetzung bei Kontextwechseln. Verwenden Sie sichere Löschmuster, die bei Bedarf mehrfach überschreiben. Überprüfen Sie die Nullsetzung durch Tests. Berücksichtigen Sie Datenrückstandseigenschaften der Speichertechnologie. Halten Sie FIPS-140-2/3 Nullsetzungsanforderungen für kryptographische Module ein.

Häufige Auswirkungen

Auswirkung	Details
Vertraulichkeit	Bereich: Vertraulichkeit Anwendungsdaten lesen – Die Schwere der Informationsoffenlegung hängt davon ab, welche sensiblen Daten durch zurückgehaltene Registerwerte exponiert werden. Kryptographische Schlüssel und Passwörter sind hochwertige Ziele.

Beispielcode und Lösung

Verwundbarer Code

// VERWUNDBAR: SHA256-Wrapper lässt Datenregister ungelöscht

module vulnerable_sha256_wrapper (
    input wire clk,
    input wire reset_n,
    input wire [255:0] data_in,
    input wire data_valid,
    output reg [255:0] hash_out,
    output reg hash_valid
);

    reg [255:0] input_data_reg;
    reg [255:0] intermediate_hash;

    always @(posedge clk or negedge reset_n) begin
        if (!reset_n) begin
            input_data_reg <= 256'h0;
            intermediate_hash <= 256'h0;
            hash_out <= 256'h0;
            hash_valid <= 1'b0;
        end
        else if (data_valid) begin
            input_data_reg <= data_in;
            intermediate_hash <= compute_sha256(data_in);
            hash_out <= intermediate_hash;
            hash_valid <= 1'b1;
        end
        // VERWUNDBAR: Daten bleiben in Registern nach Hash-Fertigstellung
        // Kein Löschen von input_data_reg oder intermediate_hash
    end

endmodule

Sichere Lösung

// SICHER: SHA256-Wrapper mit korrekter Nullsetzung

module secure_sha256_wrapper (
    input wire clk,
    input wire reset_n,
    input wire [255:0] data_in,
    input wire data_valid,
    input wire clear_registers,  // Explizites Löschsignal
    output reg [255:0] hash_out,
    output reg hash_valid,
    output reg registers_cleared
);

    reg [255:0] input_data_reg;
    reg [255:0] intermediate_hash;

    always @(posedge clk or negedge reset_n) begin
        if (!reset_n) begin
            input_data_reg <= 256'h0;
            intermediate_hash <= 256'h0;
            hash_out <= 256'h0;
            hash_valid <= 1'b0;
            registers_cleared <= 1'b1;
        end
        else if (clear_registers) begin
            // SICHER: Explizite Nullsetzung aller sensiblen Register
            input_data_reg <= 256'h0;
            intermediate_hash <= 256'h0;
            hash_out <= 256'h0;
            hash_valid <= 1'b0;
            registers_cleared <= 1'b1;
        end
        else if (data_valid) begin
            input_data_reg <= data_in;
            intermediate_hash <= compute_sha256(data_in);
            hash_out <= intermediate_hash;
            hash_valid <= 1'b1;
            registers_cleared <= 1'b0;
        end
    end

endmodule

// SICHER: Software mit korrekter Hardware-Nullsetzung

void secure_crypto_operation(uint8_t* key, uint8_t* data, size_t len) {
    crypto_hw_load_key(key);
    crypto_hw_encrypt(data, len);

    // SICHER: Schlüssel nach Gebrauch aus Hardware löschen
    crypto_hw_zeroize_key();

    // Überprüfen, dass Schlüssel gelöscht wurde
    if (!crypto_hw_verify_key_cleared()) {
        panic("Schlüssel-Nullsetzung fehlgeschlagen!");
    }
}

// Kontextwechsel-Handler
void context_switch_handler(void) {
    // Vor Wechsel zu neuem Benutzer/Prozess gesamten Krypto-Zustand löschen
    crypto_hw_zeroize_all();
    hash_hw_zeroize_all();

    if (!verify_all_crypto_hw_cleared()) {
        security_violation_handler();
    }
}

---

CVE-Beispiele

Register-Nullsetzungsfehler wurden in kryptographischen Hardware-Beschleunigern gefunden, bei denen sensible Schlüssel oder Daten nach Abschluss der Operationen zugänglich blieben.

---

Verwandte CWEs

• CWE-226: Sensitive Information in Resource Not Removed Before Reuse (übergeordnet)
• CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer (verwandt)
• CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information (verwandt)

---

Referenzen

1. MITRE Corporation. "CWE-1239: Improper Zeroization of Hardware Register." https://cwe.mitre.org/data/definitions/1239.html
2. FIPS PUB 140-2: Security Requirements for Cryptographic Modules
3. Gutmann, P. "Data Remanence in Semiconductor Devices" (USENIX Security 2001)
4. HACK@DAC'21 OpenPiton SoC-Beispiele