Sicherheit interne BUS Systeme und Flash Speicher

Die Daten (Flash-Inhalte) werden verschlüsselt und signiert, nicht die 
Kommunikation selbst. Man kann eine I2C-Verbindung nicht verschlüsseln, 
wenn man noch mit dem Sensor reden will.

Sicherheit kostet Zeit, Geld und Komfort. Verrechne Aufwand und Nutzen 
und entscheide danach - das Stichwort "Sicherheitskonzept" wurde schon 
genannt.

Im Übrigen: Kryptographie löst keine Probleme. Sie transformiert nur 
jedes Problem in ein Schlüsseltausch-Problem.

Prinzipiell ist jegliche Verschlüsselung dieser Art für die Katz, wenn 
der Schlüssel aus der Firmware ausgelesen wird.
Das endet schliesslich entweder in Security by Obscurity (Key gut 
verbergen), oder man hat eben eine Plattform, wo die Firmware nur schwer 
ausgelesen werden kann und Debug-Schnittstellen (JTAG, SWD) wirklich, 
aber auch wirklich deaktiviert werden können.

Flash schrieb:
> Gibt es solche Sicherheitslücken in euren System auch? Muss die
> "PCB-interne-Kommunikation" also jede UART, SPI und I2C Schnittstelle
> verschlüsselte Daten verschicken, oder verschlüsselt ihr erst wenn die
> Daten das eigentliche Gerät verlassen?

Darauf lässt sich eigentlich pauschal keine Antwort geben. Szenario?
Ich nehme an, du meinst Flash (Sensoren verschlüsseln typischerweise 
nicht).
Wenn ich nicht will, dass mir jemand einen General-Key einfach so 
ausliest, packe ich ihn in's "distributed ROM" oder on-chip-Flash des 
FPGA. Das ist recht billige 'Obscurity'.

Flash schrieb:
> Ich habe zum Beispiel ein Thema, dass ein WLAN Modul per UART und AT
> Befehlen genutzt wird. Dort wird eine SSID und ein Passwort zwingend im
> Klartext übermittelt, prinzipiell kann so etwas also stets mitgelesen
> werden, wenn man denn Zugang zu der Hardware erhält...

> Gibt es solche Sicherheitslücken in euren System auch?

Ja/Nein/kommt drauf an.

> Muss die
> "PCB-interne-Kommunikation" also jede UART, SPI und I2C Schnittstelle
> verschlüsselte Daten verschicken, oder verschlüsselt ihr erst wenn die
> Daten das eigentliche Gerät verlassen?

Ja/Nein/kommt drauf an.

Was hier fehlt ist ein präzises Angreifermodell, das genau beschreibt 
was und gegen welche Angriffe/Angreifer geschützt werden muss (bzw. bis 
zu welchem Grad).

Beispiel hier: WLAN-Modul und Angreifer hat physischen Zugriff auf das 
Gerät. Passwort soll geschützt werden, gegen welche Angriffe? Einfaches 
mitlesen (da z.Z. unverschlüsselt)? Dann reicht vielleicht ein Modul mit 
verschlüsselter Kommunikation oder darf der Angreifer mehr? 
Fault-Injections, (differential) Power-Analysis, andere Seitenkanäle, 
die angegriffen werden können. Sind's nur nicht-invasive Angriffe oder 
auch invasive? Wie anfällig ist die Software?

Arc N. schrieb:
> Wie anfällig ist die Software?

Und: Wie bekannt ist das WLAN-Passwort?

S. R. schrieb:
> Arc N. schrieb:
>> Wie anfällig ist die Software?
>
> Und: Wie bekannt ist das WLAN-Passwort?

Das WLAN-Passwort ist doch mindestens auch dem Administrator des 
dortigen Netzes bekannt, der muss also gar nichts aufschrauben. Die 
Frage ist: interessiert das irgendwen was die Kiste da sendet und 
empfängt? Kann man Schindluder treiben wenn man gefälschte Pakete 
einschleusen kann? Kann man einbrechen und eigenen Schadcode 
installieren und zur Ausführung bringen der andere Geräte im Netzwerk 
angreift?