Ist es eine schlechte Praxis, Zertifikate im externen Speicher zu behalten?

Wir arbeiten an AWS-IoT mit einem STM32-Mikrocontroller.

Bis heute haben wir die Zertifikate auf den Blitz geschrieben und den Blitz für externes Lesen gesperrt. Mit zunehmendem Anwendungscode erhalten wir weniger Speicherplatz auf dem Flash. Daher planten wir, das Zertifikat extern auf eine SD-Karte / ein EEPROM zu verschieben und zu lesen, wann immer es benötigt wird, bevor eine Verbindung zu AWS-IoT hergestellt wird.

Anmerkungen:

• Die für das Objekt geschriebene Richtlinie erlaubt nur Geräten mit bestimmten Namen, eine Verbindung zu diesem bestimmten Zertifikat herzustellen.

• Das Ding darf nur auf 2 Kanälen (seinem Namen und einem Datenfeed-Kanal) veröffentlichen, die mit einem Datenprozessor verbunden sind, der alle unerwünschten Pakete ignoriert, die zu ihm kommen.

• Wenn das Objekt ein anderes Thema veröffentlicht / abonniert, trennt AWS das Objekt sofort.

Wenn ich feststelle, dass ein Gerät gestohlen wurde, deaktivieren wir den Schlüssel vom Server.

Was kann ein Exploiter mit den Zertifikaten (RootCA, Serverschlüssel, Clientschlüssel) tun?

Ist es eine schlechte Praxis, Zertifikate für einen solchen Verwendungszweck auf einem externen Speicher aufzubewahren, auf den ein Exploiter zugreifen kann?

Sie erwähnen "Zertifikate", aber aus dem Zusammenhang heraus denke ich, dass Sie sich auf zwei verschiedene Dinge beziehen.

• Ihr Gerät verfügt über einen privaten Schlüssel, der für dieses Gerät eindeutig ist und außerhalb des Geräts nicht bekannt ist. Dieser Schlüssel identifiziert Ihr Gerät. Jeder, der auf diesen Schlüssel zugreifen kann, kann sich als Gerät ausgeben. Das bedeutet, dass sie insbesondere:

  • Veröffentlichen Sie gültige, aber falsche Daten auf den Kanälen, auf denen Ihr Gerät rechtmäßig veröffentlicht werden darf.
  • Veröffentlichen Sie ungültige Daten, durch die das legitime Gerät gesperrt wird.
  • Legen Sie je nach Anwendungsfall möglicherweise einige private Informationen des Besitzers des Geräts offen.

  Dieser private Schlüssel sollte besser vertraulich bleiben.

• Ihr Gerät verfügt wahrscheinlich über mindestens einen öffentlichen Schlüssel, mit dem es erkennen kann, mit welchen Servern es spricht. Es ist in Ordnung, wenn jemand diesen Schlüssel lesen kann: Er ist öffentlich. Ein Angreifer sollte den Schlüssel jedoch nicht ändern können. Andernfalls könnten sie mit dem Gerät kommunizieren und sich als Server ausgeben. Dies könnte es ihnen ermöglichen, Dinge zu tun wie:

  • Übertragen Sie ein Firmware-Update auf das Gerät.
  • Übertragen Sie ein Konfigurationsupdate auf das Gerät.
  • Lassen Sie das Gerät seine Daten an einen anderen Ort hochladen.

Die gute Nachricht ist, dass diese Bedrohungsanalyse eigentlich nicht sehr relevant ist. Sie müssen keine Sicherheit opfern ! (Zumindest nicht Vertraulichkeits- und Authentizitätseigenschaften - Wenn Sie Daten extern speichern, wird die Verfügbarkeit beeinträchtigt, da dies ein Teil des Systems ist, der möglicherweise verloren geht.)

Solange Sie über mindestens 128 Bit Speicher verfügen, in den Sie mindestens einmal schreiben können, und über mehr verfügen, können Sie eine sichere Remotespeicherlösung implementieren. Verwenden Sie den Speicherplatz auf dem Gerät mit begrenztem Speicherplatz, um einen geheimen Schlüssel zu speichern. Dieser geheime Schlüssel muss pro Gerät eindeutig sein. Der STM32 verfügt über ein Hardware-RNG, sodass Sie es beim ersten Start auf dem Gerät generieren können. Wenn Ihr Gerät kein Hardware-RNG hat, können Sie den Schlüssel an einem sicheren Ort außerhalb des Geräts generieren und in das Gerät injizieren.

Verwenden Sie mit diesem Schlüssel eine authentifizierte Verschlüsselung Sie für Dinge, die Sie außerhalb des Geräts speichern. Wenn Sie einige Daten aus einem externen Speicher lesen möchten, laden Sie sie, entschlüsseln und überprüfen Sie sie. Wenn Sie Daten in einen externen Speicher schreiben möchten, verschlüsseln und signieren Sie sie. Dies garantiert, dass die Daten so vertraulich und authentisch sind wie die Daten im internen Speicher.

Authentifizierte Verschlüsselung reicht aus, um die Vertraulichkeit und Authentizität der Daten zu gewährleisten, garantiert jedoch nicht ganz deren Integrität .

• Wenn mehr als ein Datenblock vorhanden ist, kann das Gerät beim Zurücklesen eines Datenblocks nicht sicher sein, ob dies der richtige Block ist. Lösung: umfasst eine eindeutige Kennung in dem Inhalt der einzelnen Brocken (zB startet jeden Brocken mit einem "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Wenn Sie die Daten irgendwann aktualisieren und dann zurücklesen, können Sie nicht sicher sein, ob Sie die neueste Version dieser Daten erhalten. Wenn jemand den externen Speicher ändern kann, kann er keine gefälschten Daten speichern, da dies die Authentizitätsprüfung nicht bestehen würde. Er kann jedoch alte Daten wiederherstellen, da das, was früher authentisch war, immer noch authentisch ist. Lösung: Fügen Sie in jeden Datenblock, der extern gespeichert wird, einen Zähler ein, den Sie jedes Mal erhöhen, wenn Sie eine neue Version dieses Blocks schreiben. Stellen Sie beim Zurücklesen eines Blocks sicher, dass es sich um die erwartete Version handelt.

Um zu vermeiden, dass ein Gerät blockiert wird, falls der externe Speicher beschädigt ist oder auf andere Weise verloren geht, sollten Sie in dem begrenzten Speicherplatz, den Sie im internen Speicher haben, Vorrang vor allem haben, was zum Zurücksetzen des Geräts in einen „guten“ Zustand erforderlich ist, z. B. ein Zurücksetzen auf die Werkseinstellungen . Die zweite Priorität sind Leistungsüberlegungen.

Ein bisschen Kontext

Da Sie MQTT mit AWS IoT verwenden, wird erwartet , dass Sie zur Authentifizierung und Sicherheit X.509-Zertifikate verwenden . Amazon hat ein paar Anleitungen, wie Sie Ihre Zertifikate sichern sollten. Deshalb zitiere ich das hier:

Mit Zertifikaten können asymmetrische Schlüssel mit Geräten verwendet werden. Dies bedeutet, dass Sie private Schlüssel in einen sicheren Speicher auf einem Gerät brennen können, ohne dass das vertrauliche kryptografische Material jemals das Gerät verlässt.

Da Sie derzeit die STM32 der mit Read Out Schutz (RDP), alle , aber die meisten bestimmt Angreifer Schwierigkeiten haben , Ihre Zertifikate in Ihrem aktuellen Programm den Zugriff auf :

Der globale Ausleseschutz ermöglicht es dem eingebetteten Firmware-Code (im Flash-Speicher vorinstalliert), sich vor Reverse Engineering, Dumping mit Debug-Tools oder anderen Mitteln für aufdringliche Angriffe zu schützen.

• Stufe 0 - Kein Schutz (Standard)
• Stufe 1 - Der Flash-Speicher ist durch Debuggen oder Code-Dumping durch den im RAM geladenen Code gegen Lesen geschützt
• Stufe 2 - Alle Debug-Funktionen sind deaktiviert

Wird der externe Speicher sicher sein?

Es ist wahrscheinlich nicht so sicher . Wenn der private Schlüssel Ihres Clients gestohlen wird, kann ein Angreifer Daten senden, die scheinbar von Ihrem Gerät stammen, obwohl dies tatsächlich nicht der Fall ist. Obwohl nicht klar ist, welche Daten Sie senden, können nicht vertrauenswürdige Daten ein Sicherheitsrisiko darstellen.

Welche Teile muss ich privat halten?

Wenn Sie ein Gerätezertifikat in AWS IoT erstellen, sollte ein Bild wie das folgende angezeigt werden:

^{Bild von der Seite " Gerätezertifikat erstellen und aktivieren" der AWS IoT-Dokumentation.}

Der private Schlüssel ist das, was Sie wirklich brauchen, um ... privat zu bleiben , und sollte auf jeden Fall, wenn möglich, im lesegeschützten Speicher gespeichert werden. Der öffentliche Schlüssel und das Zertifikat können gemeinsam genutzt werden. Wenn Ihnen also der Speicherplatz ausgeht, können Sie diese sicher in einen externen Speicher verschieben. Auf der Seite finden Sie etwas mehr Kontext. Wie funktioniert SSL / TLS? bei Information Security Stack Exchange und Public-Key-Kryptographie auf Wikipedia. Ich denke, ich würde Ihnen einen schlechten Dienst erweisen, wenn ich dieses Bild nicht einfügen würde, um zu erklären, warum der private Schlüssel geheim sein muss:

.

^{Bild aus Wikipedia , öffentlich zugänglich.}

Der öffentliche Schlüssel Ihres Geräts wird von AWS IoT zum Signieren von Nachrichten verwendet, die an Ihr Gerät gesendet werden sollen (es wird jedoch nicht nachgewiesen, wer die Nachricht sendet ). Es ist also wirklich keine große Katastrophe, wenn jemand den öffentlichen Schlüssel stiehlt, weil er kein Geheimnis sein soll.

Der private Schlüssel wird von Ihrem Gerät zum Entschlüsseln von Nachrichten verwendet. Daher ist es ein etwas größeres Problem, wenn ein Angreifer dies stiehlt.

Sie haben auch gefragt, was passieren würde, wenn der Angreifer das RootCA-Zertifikat stehlen würde. Wenn jemand den privaten Schlüssel von AWS IoT gestohlen hat , wäre dies katastrophal, aber das RootCA-Zertifikat auf Ihrem Gerät ist das nicht . Das RootCA.crt, was Amazon Ihnen gibt, ist vollständig öffentlich und dient dazu, zu überprüfen, ob Sie in irgendeiner Weise angegriffen werden (höchstwahrscheinlich ein Mann in der Mitte, der vorgibt, die Server von AWS IoT zu sein).

Welchen Schaden könnte ein gehacktes Gerät anrichten?

Ihr gestohlenes Gerät kann nur die in der Richtlinie aufgeführten Aktionen ausführen . Versuchen Sie, dem Prinzip des geringsten Privilegs zu folgen . Gewähren Sie Ihrem Gerät nur die Berechtigungen, die es unbedingt benötigt . Wenn also das Schlimmste passiert, kann es nicht zu viel Chaos anrichten. Für Ihren speziellen Fall:

Das Ding darf nur auf 2 Kanälen (seinem Namen und einem Datenfeed-Kanal) veröffentlichen, die mit einem Datenprozessor verbunden sind, der alle unerwünschten Pakete ignoriert, die zu ihm kommen.

Das ist gut. Jeder Angriff sollte nur auf die beiden MQTT-Themen beschränkt werden, auf denen das Gerät veröffentlichen kann, damit es keinen großen Schaden verursacht.

Idealerweise soll Ihr Gesamtsystem so gestaltet sein, dass beim Zerlegen einer einzelnen Einheit nur diese Einheit und nicht das System im Allgemeinen zerstört wird.

Insbesondere wenn Sie Schlüssel in einem bestimmten Speicher speichern, sodass sie eine standardmäßige elektrische Schnittstelle zwischen Chips überschreiten, sollten sie nur Schlüssel sein, die bereits sicher veröffentlicht werden können oder für diese bestimmte physische Instanz des Geräts eindeutig sind.

Wenn ein einzelner Schlüssel von einem einzelnen Gerät extrahiert wird und missbraucht wird oder in einem Verkehrsaufkommen angezeigt wird, das von mehreren nicht autorisierten Klonen stammen muss, können Sie diesen Schlüssel auf der Serverseite sperren.

Ihre Schlüssel sollten natürlich die Eigenschaft haben, nicht etwas zu sein, das eine nicht autorisierte Partei entweder anhand einiger extrahierter Beispiele erraten oder ihre eigenen original kompatiblen Instanzen generieren kann - dh Sie benötigen entweder eine Aufzeichnung der Schlüssel, die Sie generiert haben, wo gültige sind Nur ein kleiner und unvorhersehbarer Teil eines riesigen Möglichkeitsbereichs. Andernfalls müssen Sie die von Ihnen generierten Schlüssel signieren und Ihr System muss nur einen Schlüssel in Kombination mit dem Signaturnachweis akzeptieren.

Sie sollten versuchen, den Clientschlüssel geheim zu halten (verstehen Sie jedoch die Auswirkungen des Verlusts (1), wie in den anderen Antworten beschrieben). Der öffentliche Serverschlüssel und das öffentliche AWS-Zertifikat sind wichtig, um auf Geräteseite zu sichern, nicht weil Sie sie dann geheim halten möchten, sondern weil ein Angreifer das Gerät durch Ersetzen des AWS-Zertifikats (auf einem gefährdeten Gerät) zur Ausführung eines Zertifikats überreden kann Tauschen Sie sich mit dem Host des Angreifers aus oder stellen Sie Ihre Kommunikation mit AWS in die Mitte.

Auf diese Weise (2) kann ein Angreifer die TLS-Sicherheit entfernen, was zu einer ausreichenden Verringerung der Sicherheit führen kann, damit er den Client-Schlüssel zurückentwickeln kann.

Aus diesem Grund ist der öffentliche Schlüssel der einzige Schlüssel, den Sie sicher in einem externen Speichergerät verfügbar machen können. Wenn Sie dies (3) ändern, kann Ihr Gerät nur gezwungen werden, eine Verbindung zu einem nicht autorisierten AWS-Dienst herzustellen, auf den vermutlich nur schwer zugegriffen werden kann. Selbst wenn nur dieser Schlüssel verloren geht, kann jemand möglicherweise einige Übertragungen abhören oder vortäuschen (z. B. wenn die TLS-Schicht irgendwie herabgestuft werden kann).

Zusammenfassend besteht das Risiko also nicht nur darin, Informationen zu verlieren, sondern es besteht auch das Risiko, dass die (angeblich vertrauenswürdige) Firmware mit nicht vertrauenswürdigen sicheren Informationen versehen wird.