Fehlender Schutz gegen Hardware-Reverse-Engineering mit IC-Bildgebungstechniken

Beschreibung

Fehlender Schutz gegen Hardware-Reverse-Engineering mit Integrated Circuit (IC) Imaging-Techniken tritt auf, wenn in Hardware gespeicherte Informationen von einem Angreifer mit der Fähigkeit, Bilder der integrierten Schaltung aufzunehmen und zu analysieren, wiederhergestellt werden können. Physische Inspektion bei hoher Vergrößerung kann gespeicherte Geheimnisse durch Techniken wie Rasterelektronenmikroskopie offenbaren. Angriffsmethoden umfassen typischerweise das Entfernen der Chip-Verpackung und die Anwendung von Bildgebungstechnologien, die von Röntgenmikroskopie bis zu invasiven Schichtentfernungstechniken reichen. Das Ziel ist die Wiederherstellung geheimer Schlüssel, Gerätekennungen, proprietärer Designs oder eingebetteten Codes. Nichtflüchtiger Speicher und Schaltkreis-Netzlisten stellen besondere Risiken dar, wobei maskiertes ROM anfälliger ist als One-time Programmable (OTP) Speicher.

Risiko

Fehlender Reverse-Engineering-Schutz hat schwerwiegende Sicherheitsauswirkungen. Geheime Schlüssel können extrahiert werden. Gerätekennungen können wiederhergestellt werden. Proprietäre Designs können gestohlen werden. Eingebetteter Code kann kopiert werden. Gefälschte ICs können produziert werden. Geklonte Geräte können auf den Markt kommen. Geistiges Eigentum wird kompromittiert. Kryptographische Sicherheit kann besiegt werden.

Lösung

Design-Teams sollten durch Bedrohungsmodellierung sicherstellen, dass die Extraktionskosten den Wert der Geheimnisse übersteigen. Schutzansätze umfassen IC-Camouflage, Obfuskation, manipulationssichere Verpackung, aktive Abschirmung und physische Manipulationserkennungssysteme. Erwägen Sie die Verwendung von verschlüsselter Speicherung mit Schlüsselableitung. Implementieren Sie Schaltkreis-Obfuskationstechniken. Verwenden Sie Anti-Tamper-Verpackung mit Erkennungsmechanismen.

Häufige Auswirkungen

Auswirkung	Details
Vertraulichkeit	Bereich: Vertraulichkeit Speicher lesen - Geheime Daten können aus dem IC extrahiert werden.
Integrität	Bereich: Integrität Reverse Engineers können gefälschte IC-Versionen produzieren.
Zugriffskontrolle	Bereich: Zugriffskontrolle Schutzmechanismus umgehen - Sicherheitsmechanismen können verstanden und umgangen werden.

Beispielcode und Lösung

Verwundbarer Code

// VERWUNDBAR: Geheimer Schlüssel in ungeschütztem ROM gespeichert

module vulnerable_key_storage (
    input wire clk,
    input wire reset_n,
    input wire [7:0] addr,
    output reg [31:0] data,
    input wire read_enable
);

    // VERWUNDBAR: Geheimer Schlüssel im Klartext-ROM gespeichert
    // Kann durch IC-Bildgebung extrahiert werden

    reg [31:0] secret_rom [0:255];

    initial begin
        // VERWUNDBAR: Hartcodierter geheimer Schlüssel im ROM
        // Diese Muster sind unter dem Mikroskop sichtbar
        secret_rom[0] = 32'h01234567;  // Schlüsselwort 0
        secret_rom[1] = 32'h89ABCDEF;  // Schlüsselwort 1
        secret_rom[2] = 32'hFEDCBA98;  // Schlüsselwort 2
        secret_rom[3] = 32'h76543210;  // Schlüsselwort 3

        // Gerätespezifische Daten ebenfalls exponiert
        secret_rom[16] = 32'h12345678; // Geräte-ID
        secret_rom[17] = 32'hDEADBEEF; // Herstellungs-ID
    end

    always @(posedge clk or negedge reset_n) begin
        if (!reset_n) begin
            data <= 32'h0;
        end
        else if (read_enable) begin
            data <= secret_rom[addr];
        end
    end

    // Angriff: Angreifer entkapelt den Chip
    // Verwendet REM zum Abbilden des ROM-Arrays
    // Liest Bitmuster direkt aus Transistörzuständen
    // Stellt alle geheimen Schlüssel wieder her

endmodule

// VERWUNDBAR: Ungeschütztes Schaltkreisdesign
module vulnerable_crypto_core (
    input wire clk,
    input wire reset_n,
    input wire [127:0] plaintext,
    input wire [127:0] key,
    input wire encrypt_start,
    output reg [127:0] ciphertext,
    output reg encrypt_done
);

    // VERWUNDBAR: Standard-AES-Implementierung
    // Schaltkreisstruktur enthüllt Algorithmusdetails

    // VERWUNDBAR: Schlüsselplanung in Netzliste sichtbar
    wire [127:0] round_keys [0:10];

    // VERWUNDBAR: Keine Obfuskation der Datenpfade
    // S-Box-Implementierung kann reverse-engineered werden

    aes_key_expansion key_exp (
        .key(key),
        .round_keys(round_keys)
    );

    // Standardrunden - leicht identifizierbar
    aes_round round_0 (.in(plaintext), .key(round_keys[0]), .out(state_0));
    aes_round round_1 (.in(state_0), .key(round_keys[1]), .out(state_1));
    // ... weitere Runden

    // Angreifer kann:
    // 1. Crypto-Kern im Die-Bild identifizieren
    // 2. Netzliste reverse-engineeren
    // 3. Implementierungsdetails verstehen
    // 4. Schwachstellen finden oder Schlüssel extrahieren

endmodule

// VERWUNDBAR: Eingebettete Geheimnisse in Firmware

#include <stdint.h>

// VERWUNDBAR: Hartcodierte Schlüssel in Firmware
// Sichtbar im Flash-Speicherabbild und bei IC-Bildgebung

static const uint8_t master_key[16] = {
    0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF,
    0xFE, 0xDC, 0xBA, 0x98, 0x76, 0x54, 0x32, 0x10
};

// VERWUNDBAR: Gerätegeheimnis im Code
static const uint8_t device_secret[32] = {
    /* 32 Bytes geheimer Daten */
};

// VERWUNDBAR: Zertifikat im Binary eingebettet
static const uint8_t device_certificate[] = {
    /* Zertifikatsdaten sichtbar im Speicherabbild */
};

void vulnerable_init_crypto(void) {
    // VERWUNDBAR: Schlüssel aus sichtbarem Speicher geladen
    load_key(master_key);

    // Angreifer, der den Flash abbildet, kann alle Geheimnisse wiederherstellen
}

Sichere Lösung

// SICHER: Geschützte Schlüsselspeicherung mit Obfuskation

module protected_key_storage (
    input wire clk,
    input wire reset_n,
    input wire [7:0] addr,
    output reg [31:0] data,
    input wire read_enable,
    // Anti-Tamper-Signale
    input wire tamper_detected,
    output reg key_destroyed
);

    // SICHER: OTP (One-Time Programmable) Fuses statt ROM verwenden
    // OTP ist schwerer zu bilden als maskiertes ROM
    wire [127:0] otp_key;
    otp_fuse_array otp (
        .read_enable(read_enable),
        .key_out(otp_key)
    );

    // SICHER: Schlüssel verschlüsselt gespeichert, nur bei Bedarf entschlüsselt
    reg [127:0] encrypted_key_storage;
    wire [127:0] decrypted_key;

    // SICHER: Gerätespezifischen Schlüssel zur Verschlüsselung verwenden
    wire [127:0] puf_key;  // Physically Unclonable Function
    puf_generator puf (
        .clk(clk),
        .challenge(128'h0),
        .response(puf_key)
    );

    // Gespeicherten Schlüssel mit PUF-Schlüssel entschlüsseln
    aes_decrypt key_decrypt (
        .ciphertext(encrypted_key_storage),
        .key(puf_key),
        .plaintext(decrypted_key)
    );

    // SICHER: Anti-Tamper-Reaktion
    always @(posedge clk or negedge reset_n) begin
        if (!reset_n) begin
            key_destroyed <= 1'b0;
        end
        else if (tamper_detected) begin
            // SICHER: Schlüssel bei Manipulationserkennung zerstoren
            encrypted_key_storage <= 128'h0;
            key_destroyed <= 1'b1;
        end
    end

endmodule

// SICHER: Schaltkreis-Obfuskationstechniken
module obfuscated_crypto_core (
    input wire clk,
    input wire reset_n,
    input wire [127:0] plaintext,
    input wire [127:0] key,
    input wire encrypt_start,
    output reg [127:0] ciphertext,
    output reg encrypt_done
);

    // SICHER: Getarnte Gatter
    // Standardzellen, die identisch aussehen, aber unterschiedliche Funktionen haben

    // SICHER: Dummy-Logikpfade
    // Zusätzliche Schaltkreise, die die Funktion nicht beeinflussen, aber RE verwirren
    wire [127:0] dummy_state_0, dummy_state_1, dummy_state_2;

    dummy_logic_path dummy_0 (
        .in(plaintext ^ key),
        .out(dummy_state_0)
    );

    // SICHER: Aufgeteilte und verteilte Schlüsselspeicherung
    // Schlüsselteile an verschiedenen Orten gespeichert
    wire [31:0] key_piece_0, key_piece_1, key_piece_2, key_piece_3;

    distributed_key_storage key_store (
        .clk(clk),
        .key_out_0(key_piece_0),
        .key_out_1(key_piece_1),
        .key_out_2(key_piece_2),
        .key_out_3(key_piece_3)
    );

    wire [127:0] reconstructed_key = {key_piece_3, key_piece_2,
                                      key_piece_1, key_piece_0};

    // SICHER: Mixed-Signal-Implementierungen
    // Kombination von digitalen und analogen Techniken

endmodule

// SICHER: Aktive Abschirmung und Manipulationserkennung
module tamper_protection (
    input wire clk,
    input wire reset_n,
    // Abschirmungsüberwachung
    input wire [7:0] shield_sensors,
    // Spannungs-/Temperaturüberwachung
    input wire voltage_in_range,
    input wire temp_in_range,
    // Lichterkennung
    input wire light_detected,
    // Ausgabe
    output reg tamper_alert,
    output reg zeroize_keys
);

    // SICHER: Aktives Abschirmungsgitter über sensitiven Schaltkreisen
    // Brüche in der Abschirmung lösen Manipulationsreaktion aus
    wire shield_intact = (shield_sensors == 8'hFF);

    // SICHER: Umgebungsüberwachung
    wire env_normal = voltage_in_range && temp_in_range;

    // SICHER: Lichterkennung (Entkapselungserkennung)
    wire package_intact = !light_detected;

    always @(posedge clk or negedge reset_n) begin
        if (!reset_n) begin
            tamper_alert <= 1'b0;
            zeroize_keys <= 1'b0;
        end
        else begin
            // SICHER: Manipulationsversuche erkennen
            if (!shield_intact || !env_normal || !package_intact) begin
                tamper_alert <= 1'b1;
                zeroize_keys <= 1'b1;
            end
        end
    end

endmodule

// SICHER: PUF-basierte Schlüsselgenerierung
module puf_key_generator (
    input wire clk,
    input wire reset_n,
    input wire generate_key,
    output reg [127:0] device_key,
    output reg key_valid
);

    // SICHER: Physically Unclonable Function verwenden
    // Schlüssel aus physischen Chip-Eigenschaften abgeleitet
    // Kann nicht durch Bildgebung extrahiert werden

    wire [255:0] puf_response;
    wire puf_ready;

    sram_puf puf_core (
        .clk(clk),
        .reset_n(reset_n),
        .challenge(256'h0),
        .response(puf_response),
        .ready(puf_ready)
    );

    // SICHER: Fehlerkorrektur für PUF-Stabilität
    wire [127:0] corrected_key;
    wire correction_valid;

    fuzzy_extractor fe (
        .puf_response(puf_response),
        .helper_data(stored_helper_data),
        .key_out(corrected_key),
        .valid(correction_valid)
    );

    always @(posedge clk or negedge reset_n) begin
        if (!reset_n) begin
            device_key <= 128'h0;
            key_valid <= 1'b0;
        end
        else if (generate_key && puf_ready && correction_valid) begin
            device_key <= corrected_key;
            key_valid <= 1'b1;
        end
    end

    // Schlüssel wird aus physischen Eigenschaften abgeleitet
    // Nirgendwo gespeichert, wo er abgebildet werden könnte

endmodule

// SICHER: Geschützte Schlüsselverwaltung

#include <stdint.h>
#include <stdbool.h>

// SICHER: Keine hartcodierten Schlüssel
// Schlüssel werden aus Hardware-PUF abgeleitet

typedef struct {
    uint8_t key[16];
    bool valid;
} derived_key_t;

// SICHER: Schlüssel zur Laufzeit aus PUF ableiten
derived_key_t secure_derive_key(void) {
    derived_key_t result = {.valid = false};

    // PUF-Antwort lesen
    uint8_t puf_response[32];
    if (!read_puf(puf_response, sizeof(puf_response))) {
        return result;
    }

    // Fuzzy Extractor mit Hilfsdaten anwenden
    uint8_t helper_data[32];
    read_helper_data_from_otp(helper_data);

    if (!fuzzy_extract(puf_response, helper_data, result.key)) {
        return result;
    }

    result.valid = true;
    return result;

    // Schlüssel niemals in Flash oder ROM gespeichert
    // Kann nicht durch IC-Bildgebung extrahiert werden
}

// SICHER: Verschlüsselte Schlüsselspeicherung mit PUF-Schutz
void secure_store_key(const uint8_t* key, size_t len) {
    // Verschlüsselungsschlüssel aus PUF ableiten
    derived_key_t puf_key = secure_derive_key();
    if (!puf_key.valid) {
        handle_error();
        return;
    }

    // Schlüssel vor Speicherung verschlüsseln
    uint8_t encrypted_key[32];
    aes_encrypt(key, len, puf_key.key, encrypted_key);

    // Verschlüsselten Schlüssel in OTP oder sicherem Speicher ablegen
    write_to_otp(encrypted_key, sizeof(encrypted_key));

    // Sensible Daten aus Speicher löschen
    secure_memzero(&puf_key, sizeof(puf_key));
    secure_memzero(encrypted_key, sizeof(encrypted_key));
}

// SICHER: Manipulationserkennungsbehandlung
void tamper_response_handler(void) {
    // SICHER: Sofortige Schlüsselzerstörung bei Manipulation
    zeroize_all_keys();

    // Krypto-Operationen deaktivieren
    disable_crypto_engine();

    // Manipulationsereignis protokollieren (falls möglich)
    log_tamper_event();

    // In sicheren Ausfallmodus wechseln
    enter_lockdown_mode();
}

// SICHER: Manipulationserkennungs-Interrupt registrieren
void init_tamper_protection(void) {
    register_interrupt(IRQ_TAMPER, tamper_response_handler);
    enable_shield_monitoring();
    enable_voltage_monitoring();
    enable_light_detection();
}

---

CVE-Beispiele

IC-Bildgebungsschwachstellen wurden in verschiedenen Kontexten demonstriert, einschließlich Extraktion kryptographischer Schlüssel aus Smartcards, Reverse Engineering proprietärer Algorithmen aus Sicherheitschips und Klonen von Hardware-Token.

---

Verwandte CWEs

• CWE-693: Schutzmekanismusfehler (Eltern)
• CWE-1388: Probleme und Bedenken beim physischen Zugang (Kategorie)
• CWE-311: Fehlende Verschlüsselung sensibler Daten (verwandt)
• CAPEC-188: Reverse Engineering (Angriffsmuster)
• CAPEC-37: Eingebettete sensible Daten abrufen (Angriffsmuster)
• CAPEC-545: Daten aus Systemressourcen ziehen (Angriffsmuster)

---

Referenzen

1. MITRE Corporation. "CWE-1278: Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques." https://cwe.mitre.org/data/definitions/1278.html
2. IEEE. "Hardware Security and Trust"
3. Springer. "Physical Attacks and Countermeasures"