Hallo zusammen Für ein LoRaWAN Gerät (node) suche ich Lösungen für sichere Hardware (Mikrocontroller, Verschlüsselung, Secure Key Storage, Tamper Detection) Dabei sollen die Keys für das LoRaWAN sicher gespeichert werden und bei einem Angriff auf die Hardware gelöscht werden. Bis jetzt habe ich folgende Varianten gefunden: - ARM Cortex MCU mit Tamper detection (z.B NXP (Freescale) Kinetis Serie) http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus:KINETIS - Externe Security Controller wie maxim integrated MAXQ1061 oder ATECC508A https://www.maximintegrated.com/en/products/digital/microcontrollers/MAXQ1061.html - LoRaWAN Secure Element TO136 von Trusted Objects http://www.trusted-objects.com/lorawan-secure-modem.html Die Anwendung der externen Kryptographie IC habe ich für symmetrische Verschlüsselungen nicht ganz verstanden. Der Plaintext geht dabei meines Wissens über I2C in den IC hinein und kommt verschlüsselt wieder heraus. Dies macht für mich wenig Sinn – Der Angreifer bekommt zwar den Key nicht zu Gesicht, kann aber seine Daten auch mit dem IC verschlüsseln. Kenn sich jemand mit solchen Kryptographie IC aus? Gibt es ander Lösungen?
Angehängte Dateien:
:
Bearbeitet durch User
Was genau muss gesichert werden? Normalerweise funktioniert das ganze nach TLS Prinzip, nur dass tls alleine keine Authentication durchführt. weiterhin musst du die Applikation näher beschreiben. In Sicherheitskreisen gilt folgendes: 1) als erstes sicherstellen dass der Gesprächspartner der ist den er vorgibt zu sein : 2-way authentication 2) sicherstellen dass daten nicht von dritten geändert wurden auf dem transportweg 3) wenn 1+2) gegeben ist Verschlüsselung optional Hier greift ecc508 ein. Zuständig für 1+2 3) erfolgt optional im mcu ( dieser muss aber wirklich hw gesichert sein wie der ecc508 pder eine smartcard, der von dir erwähnte mcu ist es nicht fa kein die shield usw). Ecc508 macht also erstmal secure key storage, darauf erlaubt es eine root CA zu bilden, signer zu bilden und eine chain of trust zu bilden. Dazu nutzt er ecdsa zum verifizieren und unterschreiben von Nachrichten und ecdh zur session key generierung mit betonung auf session key. Die session ist zeitlich begrenzt und der key damit nur kurz gültig. Sind die Informationen super confidential, sollte die Nachricht zb in mehrere teile zerlegt werden und jeweils mit einem neuen session key verschlüsselt werden. Wichtig hier: der root key aus dem der session key generiert wird kommt nie aus dem chip raus. Der ecc508 macht keine encryption das macht die mcu. Das A&O ist aber, ob ich in der Lage bin zu authenifizieren und sicherzustellen dass die daten nicht geändert wurden und ich die security chain nachvollziehen kann. Siehe Amazon AWS da wird expliziet der ecc508 empfohlen und verwendet. Genauso wolfssl.
Hallo Stefan Vielen Dank für die Informationen. Wenn ich dich richtig verstanden habe, sollen die externen Security Controller mit Asymmetrischen Verschlüsselung den Key für darauf folgende symmetrische Verschlüsselungen austauschen. Ich beschreibe meine Anwendung noch etwas genauer: LoRaWAN mit verwendung des offenen "The Things Network" kann kleine Datenmengen über weite Distanzen (bis zu 5km in der Stadt) mit wenig Energie übertragen. Dabei wird die verfügbare Übertragungszeit pro Device auf 30 Sekunden pro Tag beschränkt. Je nach Empfangsstärke sind das 200 bis 5000 Bytes pro Tag. In unserer Anwendung sollen regelmässig (z.B 5x pro Stunde) Messwerte verschlüsselt (AES) an einen Server übermittelt werden. Ich denke, dass der Overhead für die Authentifizierung mit Public und Private Key zu gross ist.
:
Bearbeitet durch User
Was für Sensorwerte sind das? Solltet ihr gerade auch Feinstaubsensoren verwenden, denkt bitte daran was ihr mit einem Messwert der zuviel ggü. den amtlichen Messstationen anzeigt für einen Schaden anrichten könnt? Esoteriker und Hypersensible nehmen dann lieber eure Messwerte als die einzig wahren an und schüren wieder Verschwörungstheorien der "Messwandlermafia" In der Esoterik gilt: "Das Ergebniss das mir am meisten für meine Ansichten oder daraus resultierende Einflusmöglichkeiten passt, ist das einzig richtige!"
Hallo Alex Vielen Dank für deinen berechtigten Einwand. In Zukunft könnten die Messwerte durchaus sensitive Daten von Stromzählern etc. sein. Zudem sollen über dieses LoRaWAN device auch Steuerungsaufgaben wahrgenommen werden. Dabei wird die Sicherheit wichtiger. Weil man Hardware-Sicherheit schlecht nachträglich einbauen kann und diese bei IoT Devices gerne vernachlässigt wird, wollen wir möglichst früh damit beginnen. Zudem muss natürlich immer abgeschätzt werden, welcher maximaler (finanzieller) Schaden entstehen kann, und welche finanziellen Mittel der Angreifer zur Verfügung hat.
Uhm, ich gehöre wirklich nicht zu denen, die als Allererstes "lass die Finger davon" schreien, aber in deinem Fall scheint mir doch die Diskrepanz zwischen deinem Vorwissen und den Anforderungen extrem hoch zu sein... wer wirklich secure storage und tamper detection haben will, dem kann man keine Lösung mit Forumswissen anbieten! Der externe Crypto Chip würde nichts weiter tun als die CPU intensiven Cryptierroutinen übernehmen, d.h. Encryption und Decryption für Dich machen (wie Du zunächst richtig vermutet hast, würde der "Urschlüssel" - der Skizze nach ein symmetrischer AES Schlüssel - den Coprozessor niemals verlassen). Da könnte sich zwar Jemand reinhängen, aber das wäre nicht meine unmittelbare Sorge - einmal weil ja Tamper Detection mit On Board wäre und zweitens Mal weil sicherlich das Wireless Protokoll Playback Attack Preventions beinhaltet, also z.B. Session Key Management oder CBC mit fortlaufenden IVs, wodurch nicht einfach ein Datenpaket in den Datenstrom eingeschmuggelt werden könnte (das würdest Du dann nach den Vorgaben des Moduls implementieren). Das ist aber nur die Spitze des Eisbergs. Security ist wie ein Schlauchboot; Du kannst noch so viele Löcher stopfen - kommt noch eines rein, geht das Boot trotzdem unter. Wenn Du nicht schon einmal durch einen Audit Prozess durchgegangen bist, hast Du nicht die geringste Ahnung, wieviel Lochpotential in so einer Architektur drin ist - das geht schon mit dem Zufallszahlengenerator los (den man so oder so braucht aber an dem ein Security Profi ca. 200 Angriffspunkte findet). Ich würde in diesem Fall die Dienste einer Zertifikationsstelle oder eines auf IT Security spezialisierten Unternehmens zurückgreifen, um zumindestens das erste Dutzend Sollbruchstellen zu identifizieren.
Vielen Dank für deine ausführliche Antwort. In der Tat sehe ich das Thema Sicherheit als sehr anspruchsvoll. Aber wenn man gar nie damit anfängt, dann lernt man nichts neues und die Sicherheit wird auch nicht besser. Damit das System Standards standhält, ist es sicher notwendig, dass spezialisiert Firmen dafür eingesetzt werden. Ich nehme an, dass mit der Tamper Detection eine Netz z.B um den I2C Bus erstellt würde, damit niemand Daten von diesem abfangen oder darauf senden kann. Wenn dies nicht vorhanden wäre und der Angreifer aus dem Plaintext die Frame (=Session) Nummer erfahren könnte, dann könnte er diese für das nächste Packet einfach erhöhen und hätte somit den Playback Schutz umgangen. Wie ich deinem Post entnehme, hast du Erfahrung im Gebiet Hardware Security. Kannst du mir einen ARM Cortex wie z.B die Kinetis Reihe empfehlen? Oder soll ich einen externen Security Kontroller verwenden?
:
Bearbeitet durch User
Definiere die Angriffsszenarien, vor denen du dich schützen willst. Vergleiche den Wert deiner Daten (bzw. die Kosten im Fall eines erfolgreichen Angriffs) mit dem Aufwand, den ein Angreifer treiben muss und dem Aufwand, den du treiben musst, um diesen Angreifer abzuwehren. Übliche Controller bieten einen Ausleseschutz (Lock-Bits, Fuse-Bits), der für die meisten Fälle hinreichend ist. Die Keys stehen dann einfach im Flash (oder EEPROM). Die Verschlüsselung ist zudem nicht zeitkritisch, darf also auch gern ein paar Sekunden pro Paket dauern (musst du mit dem Energieverbrauch abwägen, aber ein Extrachip dürfte schlechter sein). Bei den Winzpaketen ist der Key vermutlich sowieso länger als die Daten... Eine einfache Tamper-Detection kann aus einer Plombe bestehen, oder einem Taster, der im geschlossenen Gehäuse konstant gedrückt ist. Alternativ geht auch eine Lichtschranke oder sogar ein Lichtsensor. Hängt schlicht davon ab, wieviel Sicherheit du wirklich brauchst, und wieviel Sicherheit du vermarkten willst. Die haben in aller Regel sowieso nichts miteinander zu tun. Nachtrag: Crypto ist nie die Lösung des Problems. Sie transformiert das ursprüngliche Problem in ein Schlüssel-Verwaltungs-Problem. Solange du also die Schlüsselverwaltung nicht sauber gelöst hast, ist der Rest reinste Makulatur.
:
Bearbeitet durch User
Ist das ein privates Projekt? Oder für die Arbeit? Im zweiterem Fall solltest du dir professionelle Beratung suchen. Du lernst auch dabei, weil die Lösung üblicherweise mit dir zusammen geplant und entwickelt wird. Kann bei Bedarf auch nen Kontakt herstellen.
Simon W. schrieb: > Die Anwendung der externen Kryptographie IC habe ich für symmetrische > Verschlüsselungen nicht ganz verstanden. Der Plaintext geht dabei meines > Wissens über I2C in den IC hinein und kommt verschlüsselt wieder heraus. > Dies macht für mich wenig Sinn – Der Angreifer bekommt zwar den Key > nicht zu Gesicht, kann aber seine Daten auch mit dem IC verschlüsseln. > > Kenn sich jemand mit solchen Kryptographie IC aus? Du solltest erst einmal eine Sicherheitsanalyse machen um herauszufinden, was überhaupt dein Angreifermodell ist und wo bzgl. dieses Angreifermodells deine Schwachstellen liegen. Und zwar nicht nur auf die Geräte im Feld sondern auf das Gesamtsystem. Davon ausgehend sollte dann ein geeignetes Sicherheitsmodell definiert und implementiert werden. Am Ende könnte das Ergebnis sogar sein, dass du jeden x-beliebigen Controller nehmen und die Security in Software implementieren kannst, solange der Debug-Port dichtgemacht wird. Nicht jeder Angreifer verfügt über die Mittel um z.B. Side-Channel- oder Hardware-Angriffe zu fahren. Und die, die es können haben möglicherweise in diesem speziellen Anwendungsfall gar kein Interesse daran, da das zu erreichende Ziel es nicht wert ist. Einfach einen Security-Controller in das System zu kippen und das Beste zu hoffen ist selten zielführend. Was nützt dir die beste Security-Implementierung, wenn am Ende jemand per Social-Engineering Zugriff auf das Backend erhält und dort bequem sämtliche Daten oder sogar die Geräteschlüssel abschnorcheln kann.
>Du solltest erst einmal eine Sicherheitsanalyse machen um >herauszufinden, was überhaupt dein Angreifermodell ist und wo bzgl. >dieses Angreifermodells deine Schwachstellen liegen. Und zwar nicht nur >auf die Geräte im Feld sondern auf das Gesamtsystem. Davon ausgehend >sollte dann ein geeignetes Sicherheitsmodell definiert und implementiert >werden. >wenn am Ende jemand per Social-Engineering >Zugriff auf das Backend erhält und dort bequem sämtliche Daten oder >sogar die Geräteschlüssel abschnorcheln kann. Genau! Technisch ist es eine "analoge" Lösung Messwerte (Luftdruck, Stromzählerenergieverbauch) über einen verschlüsselten Kanal zu senden. Ein Angreifermodell für einen abrechnungsrelevanten Stromzähler($$$) in einem Privathaushalt hat ein anderes Modell als den Luftdruck eines Sensors in eine Zentrale eines "Opensource-Wetterdaten"-Projektes zu übertragen. Sollte die Anwendung im KRITUS Umfeld(z.B. Stromversorger) sein, sind im Gesetz "State-of-the-art" Vorgaben definiert. Ein professioneller Auditor würde beispielsweise die Nase rümpfen, wenn der vorgeschlagene persistente symmetrische AES-Key nicht regelmässig ausgetauscht wird. Man kann sehr wohl bei kleinen Installationen TLS/IPSEC/SSH basierte asymmetreiche Verfahren verwenden! Bei den geringen Datenmengen wuerde eine ECDH/ECDSA wohl einmal am Tag ausreichen. Zurück zum Design des Gesamtsystem: Nehmen wir an, die Sensoren im Feld sind "sicher" (nach einer Definition, die man niederschreiben muss, denn wer im Besitz der Hardware ist und genügend finanzielle Mittel --- Angreifermodell --- hat, kommt in den entsprechenden Laboren an fast alles ran...), was ist mit der zentralen Stelle? Nehmen wir mal an, Deine zentrale Infrastruktur sammelt Stromzählerdaten. Wie ist denn da der zentrale Zugriff auf die Daten gestaltet? Kann ein von der Mafia quersubventionierter Mitarbeiter die Daten so auswerten, dass er erkennt wann die Kunden im grossen Sommerurlaub sind und die Einbruchkommandos losschicken? (Stichwort: organisatorische und personelle Sicherheit). Ich weiss, das interessiert einen Techniker erstmal nicht, aber der Securityaudit erfolgt in der Regel top-down. Tampersicherheit würde ich erstmal ausklammern. Taster sehe ich beim ersten Gerät, dann weiss ich, wo ich bohren muss und was zu brücken ist... Ich habe (akkuflankierte) Boxen gesehen, die Infrarotsensoren und Ultraschallkomponenten hatten fuer sensitive Anwendungen, die dann den Schluessel löschen, wenn der Akku zuneige geht und man die Teile nicht wie rohe Eier behandelt. Die HSMs bei Grossrechnern haben Sensoren drin, die eine Keylöschung bewirken, wenn sie sich unter einem Röntgen wähnen. Wenn man die im Flugzeug transportiert (Höhenstrahlung) und man legt Wert auf den Erhalt der Schlüssel, muss man spezielle Maßnahmen ergreifen... Wirkliche über Tasterchen hinausgehende Tampersicherheit ist teuer, wieder vom Angreifermodell abhängig und leider kaum dokumentiert. Für die meisten Angreifermodelle sollten aber EAL-zertifizierte Smartcards ausreichen, die haben Strukturen auf Die-Ebene "dazugebaut", die zumindest für ein normales Halbleiterlabor die Analyse zu einer extremen Knobelei werden lassen. Wie oben schon erwähnt: Krypto ist nicht trivial, man nimmt in dem Bereich etwas, was sich vielfach bewährt hat und abgehangen ist (z.B. OpenSSL, LibreSSL), die haben die ganzen Bugs und Seitenkanalangriffe (hoffentlich) schon hinter sich :-) Sollte es etwas Zertifikatsbasiertes werden (da es hier nur gestreift worden ist): Die Sicherheit der CA bzw. der CA-ausgebenden Kette ist essentiell. Auch da kann man sich Inspirationen nichttechnischer Art an den Betriebsbedingungen des Signaturgesetzes holen, technisch könnte das eine Windows-CA oder gar ein (standalone) Linux auch hinbekommen... Was passiert mit kompromittieren Sensoren (Stichwort OCSP, personelle Organisation) und wie passt die CA-Infrastruktur im Officebereich (Replacement z.B. 3 Jahre) zum Produktlifecycle der Sensoren (eher so Richting 10J gehend).
Vielen Dank für eure ausführlichen Beiträge! Tiramisu schrieb: > Man kann sehr wohl bei kleinen > Installationen TLS/IPSEC/SSH basierte asymmetreiche Verfahren verwenden! > Bei den geringen Datenmengen wuerde eine ECDH/ECDSA wohl einmal am Tag > ausreichen. Ich habe LoRaWAN boards gefunden, die asymmetrische Verschlüsselung (Elliptic Curve Cryptography) mit dem ATECC508 von Microchip/Atmel verwenden. ATECC508: http://www.microchip.com/design-centers/security-ics/cryptoauthentication/ecc SODAQ Microchip ExLoRer LoRaWAN Test-Board: https://www.thethingsnetwork.org/forum/t/sodaq-microchip-explorer/4111/15 https://shop.sodaq.com/en/explorer-eu.html
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.