Sicherheitsmechanismen

Der WvdS Crypto Service implementiert mehrere Schutzmechanismen, die automatisch aktiv sind. Sie muessen nichts konfigurieren.


Rate Limiting

Schuetzt vor Denial-of-Service (DoS) Angriffen durch Ueberlastung.

Parameter Wert
Max Requests/Sekunde 1000
Burst-Toleranz 100
Cooldown 100 ms

Verhalten bei Ueberschreitung:

Request --> [Rate Limiter] --> Status: 0x07 (RATE_LIMITED)
                           --> Keine Crypto-Operation ausgefuehrt

Client-Empfehlung:

int send_with_retry(const uint8_t* request, size_t len) {
    int retry = 0;
    int delay_ms = 100;
 
    while (retry < 5) {
        send_request(request, len);
        int status = get_response_status();
 
        if (status != 0x07) return status;  // Nicht rate-limited
 
        usleep(delay_ms * 1000);
        delay_ms *= 2;  // Exponential backoff
        retry++;
    }
    return -1;  // Timeout
}

Nonce-Tracking

Nonce-Reuse = Katastrophe

Bei AES-GCM fuehrt die Wiederverwendung einer Nonce zur vollstaendigen Kompromittierung beider Klartexte!

Der Crypto Service schuetzt aktiv vor Nonce-Reuse:

Fuer Encrypt

Fuer Decrypt

Hinweis: Das Nonce-Tracking ist pro Key-ID. Bei Key-Rotation wird der Tracker zurueckgesetzt.


Input Validation

Alle Eingaben werden vor der Verarbeitung geprueft:

Pruefung Fehler-Code
Magic Byte != 0xC7 0x01 (INVALID_HEADER)
Unbekannter Request-Type 0x02 (INVALID_TYPE)
Payload-Laenge falsch 0x03 (INVALID_PAYLOAD)
Key-ID nicht vorhanden 0x04 (KEY_NOT_FOUND)
Payload > 64 KB 0x09 (PAYLOAD_TOO_LARGE)

Keine Exceptions:

Der Service wirft keine Exceptions. Alle Fehler werden ueber Status-Codes zurueckgemeldet.


Max Payload Size

Limit 64 KB (65536 Bytes)

Gruende:

Grosse Daten verschluesseln:

// Chunked Encryption fuer grosse Dateien
#define CHUNK_SIZE (60 * 1024)  // 60 KB pro Chunk
 
int encrypt_large_file(FILE* in, FILE* out) {
    uint8_t buffer[CHUNK_SIZE];
    size_t bytes_read;
    uint32_t chunk_id = 0;
 
    while ((bytes_read = fread(buffer, 1, CHUNK_SIZE, in)) > 0) {
        // AAD enthaelt Chunk-ID fuer Reihenfolge-Schutz
        char aad[32];
        snprintf(aad, sizeof(aad), "chunk:%u", chunk_id++);
 
        uint8_t ct[CHUNK_SIZE + 28];
        size_t ct_len;
        uint8_t nonce[12], tag[16];
 
        encrypt_message(buffer, bytes_read, aad, strlen(aad),
                       ct, &ct_len, nonce, tag);
 
        fwrite(nonce, 1, 12, out);
        fwrite(tag, 1, 16, out);
        fwrite(ct, 1, ct_len, out);
    }
    return 0;
}

Zeroize on Drop

Alle sicherheitskritischen Daten werden nach Verwendung ueberschrieben:

Implementierung:

// Compiler-optimierung verhindern
static void secure_zero(void* ptr, size_t len) {
    volatile uint8_t* p = (volatile uint8_t*)ptr;
    while (len--) *p++ = 0;
}

L4Re Isolation

Der Crypto Service laeuft als isolierter L4Re Task:

+---------------------------------------------------------------+
|                    L4Re Microkernel                           |
+---------------------------------------------------------------+
|     |              |              |              |            |
|  +--+--+       +---+---+      +---+---+      +---+---+        |
|  | Sigma0 |    | Moe   |      | Crypto |     | OEM   |        |
|  | (Root) |    | (Mem) |      | Service|     | Gateway|       |
|  +--------+    +-------+      +--------+     +--------+        |
|                                   |              |             |
|                                   +--------------+             |
|                                   NUR diese IPC                |
+---------------------------------------------------------------+

Sicherheitsgarantien:


Troubleshooting

Symptom Moegliche Ursache Loesung
Status 0x04 dauerhaft Key-Storage korrupt Keys neu generieren
Status 0x07 haeufig Request-Rate zu hoch Batching, Caching
Status 0x08 Key-Rotation vergessen Neuen Key generieren
Langsame Performance FIPS-Modus + Debug Release-Build nutzen
Speicherleck Responses nicht verarbeitet Shared Memory clearen

< API-Referenz | Weiter: Compliance >