Sicherheitsbewertung einer Legacy-SSL/TLS-Implementierung auf einem IoT-Gerät
Ich mache eine Sicherheitsbewertung zur Kommunikationssicherheit eines Legacy-IoT-Geräts. Ziel ist es, Sicherheitslücken im aktuellen Design/Implementierung zu bewerten und zu finden.
Der Bewertungsmodus ist manuell, hauptsächlich unter Bezugnahme auf vorhandenes Design und Code. Dies ist nur clientseitig am Gerät; während server ein Cloud-basierter Server ist. Das Gerät verwendet ein GSM-Modul (SIMCom SIM900) und stellt HTTPS-Kommunikation mit dem Server über das Internet unter Verwendung von GSM-AT-Befehlen her.
Basierend auf meinem Verständnis von SSL/TLS erwäge ich die folgenden Parameter oder Kriterien für diese Bewertung:
a. Version des TLS-Protokolls
b. Cipher Suites verwendet
c. Zertifikats- und Schlüsselverwaltung
d. Auf dem Gerät installierte Root-CAs
e. Eingebetteter PKI-Aspekt für das Geräteidentitätsmanagement
f. Hardware-Kryptoaspekt (SHE/TPM)
Mache ich es richtig? Obwohl ich denke, dass die obige Parameterliste nicht spezifisch für die Geräte-HW/SW-Plattform ist; eher generisch. aber ich denke so sollte es sein! Ich meine, die Parameterliste wird ziemlich gleich sein; Die tatsächliche Bewertung dieser hängt jedoch von den Sicherheitsanforderungen und anderen Aspekten wie dem Geräte-Footprint und seiner Plattform usw. ab.
Ist die von mir in Betracht gezogene Bewertungsparameterliste gut und angemessen?
Antworten
Das ist ein guter Anfang, aber eine gründliche Bewertung müsste viel tiefer gehen. Zum Beispiel:
Wie generiert der Client Zufallszahlen? Wird ein CSPRNG verwendet ? Oder verwendet es einen schwachen Zufallszahlengenerator, wie er in früheren Versionen von Netscape Navigator verwendet wurde, bei dem ein passiver Angreifer die für die Sitzungsschlüssel generierten Zufallszahlen erraten und so den Chiffretext entschlüsseln konnte, der über das Netzwerk ging.
Gibt der Client Informationen preis, wenn er auf einen Padding-Fehler stößt? Wenn ja, dann könnte es anfällig für einen Padding Oracle-Angriff sein , wie es beim Steam Gaming Client der Fall war .
Wie implementiert der Kunde ECDSA ? Generiert der Client für jede Signatur, die er erstellt , ein neues zufälliges k ? Ist dies nicht der Fall, kann ein passiver Angreifer möglicherweise nach Beobachtung einiger Signaturen den privaten Signaturschlüssel berechnen, wie dies bei der Sony Playstation 3 der Fall war .
Dies sind nur einige Beispiele. Aber wie Sie sehen können, können subtile Fehler bei der Implementierung der Kryptographie katastrophale Folgen haben. Aus diesem Grund ist Kryptografie so schwer richtig zu machen.