secure Bootloader over BLE , Cyber Resilience Act und RED

Mat. K. schrieb:

musste mich drum kummern!

Alles klar. Danke für Info.

Was RED und CRA tatsächlich fordern:

Signierter Bootloader (Pflicht durch die Hintertür): Ein Angreifer darf die Firmware nicht durch eine eigene ersetzen können. Ohne einen Secure Bootloader, der Signaturen prüft, lässt sich diese Kernanforderung der Konformität kaum erfüllen.

Verschlüsselter Bootloader/Firmware (Optional): Die Verschlüsselung der Firmware (z. B. AES-verschlüsselt im Flash) dient dem Schutz Ihres geistigen Eigentums (Reverse Engineering) oder dem Schutz von Geheimnissen auf dem Gerät. Weder RED noch CRA fordern, dass der Code selbst für Dritte unlesbar sein muss, solange er nicht unbefugt verändert werden kann.

... und man muss wohl alle Möglichkeiten, den Bootloader selbst zu ersetzen, verhindern. Das geht anscheinend so weit, dass in Produkten Platinenpads zum Flashen des Bootloaders inzwischen verboten sind. Oder interpretiere ich das falsch?

LG, Sebastian

Sebastian W. schrieb:

Das geht anscheinend so weit, dass in Produkten Platinenpads zum Flashen des Bootloaders inzwischen verboten sind. Oder interpretiere ich das falsch?

Dann müssten ja aber auch die Pins am Controller, die auf das "zum flashen"-Pad kommen, abgeknippt werden, sonst geht man einfach an den Pin statt ans Pad. So richtig ausgereift klingt das irgendwie nicht, ich steck aber auch nur wenig bis gar nicht in der Materie...

Du interpretierst das falsch (haha, hier gibt's kein falsch und richtig. Das ist alles Auslegungssache und im Zweifelsfall muss ein Richter entscheiden). Mein Verständnis: ganz wichtig ist der "intended use". Wenn deine Platine also dafür gedacht ist ohne Gehäuse im öffentlichen Raum zu hängen, dann wären offene Pins zum flashen wahrscheinlich problematisch. Aber selbst das wäre wahrscheinlich okay, wenn du das in deiner Risikoanalyse so identifiziert hättest, aber du und andere "Security-Experten" zur Einschätzung kommen, dass man schon sehr talentiert sein müsste um das zu machen ("Attacker Level"). Also kurz und knapp, alles möglich. Keiner weiß was richtig ist, ein Traum für Berater und Schlangenöl Verkäufer.

Genau so siehts aus. Wir sehen in unserem Umfeld im Bereich CRA alles von "wir müssen nach der Risikoanalyse nix machen" bis hin zu "wir brauchen zwingend Secure boot/update inkl. unsere eigenen PKI". Das Thema macht genau null Freude. Entweder man macht zuviel -> teuer oder zu wenig -> gefährlich. Was genau für welches Produkt zu machen ist weiß keiner so richtig.

J. T. schrieb:

Sebastian W. schrieb:

Das geht anscheinend so weit, dass in Produkten Platinenpads zum Flashen des Bootloaders inzwischen verboten sind. Oder interpretiere ich das falsch?

Dann müssten ja aber auch die Pins am Controller, die auf das "zum flashen"-Pad kommen, abgeknippt werden, sonst geht man einfach an den Pin statt ans Pad. So richtig ausgereift klingt das irgendwie nicht, ich steck aber auch nur wenig bis gar nicht in der Materie...

Ist beides falsch und auch nicht wirklich sicher, sondern eher "security by obscurity". In der Regel lassen sich die entsprechenden Programmier- und Debugschnittstellen per Fuse abschalten. Abgesehen davon bootet ein Controller mit sicherer Hardware und aktiviertem Secure Boot keinen Bootloader, der nicht passend signiert ist.

Mit freundlichen Grüßen Thorsten Ostermann

Es geht beim CRA nicht darum wirklich sicher zu sein, sondern Bürokratie zu schaffen. Das ganze läuft über einen Risiko basierten Ansatz. Wenn etwas nicht ohne weiteres zugänglich ist, braucht ein Angreifer eben mehr Motivation und auch mehr Können um ein Asset zu bedrohen. Und damit kann es eben passieren, dass ein Gehäuse davor ausreichend ist, damit Du und die 3 Hanseln, die du für kompetent hälst, das Risiko so bewerten, dass alles okay ist.

Wenn du das einfach und schnell abhandeln willst, ist eben zu empfehlen sich keinen Thorsten Ostermann (nix gegen dich) in die Risikoanalyse zu holen 😉

Bei CRA muss jetzt erst mal nur definiert sein, dass / wie man ein einem Risiko, das jemand gemeldet hat, um zu gehen hat und entsprechend die fristen einhalten. Das kann man allgemein beschreiben, gültig für alles SW / HW. Der Sinn dahinter ist ja nur, dass man bei einem Risiko weis wie man das meldet und dass man überhaupt was machen muss.

Für Ende nächsteb Jahres werden dann die anderen Dokumente benötigt. Risikoabschätzung für eine Funktion und ebenfalls eine Möglichkeit wie man die kritische Funktion deaktivieren kann, sowie eine SBOM um schneller sehen zu können welche Komponenten in welchen Projekten verwendet sind.

Beispiel: Man kann eine automatisierte Nachricht wo hin schiken. Risikominimierung: Der Benutzer muss das erst mal aktivieren und kann es jederzeit deaktivieren. Aufwand den man damit hat: Eigentlich keiner, nur dass es nochmals in einem extra Risiko-Dokument erwähnt sein sollte. Vorgabe von CRA: So ein Feature, das jemand ausnutzen könnte, muss bei Auslieferungszustand deaktiviert sein. Was ja hoffentlich schon jeder so macht.

Wie macht man es eigentlich mit dem Löschen hier im Forum? Da sollte eigentlich alles gelöscht werden was jemand mal als Freeware hier reingestellt hat.

Ich sehe es so: Es wird sehr viel Freeware in nächster Zeit einfach verschwinden. Weil niemand hat Lust für kostenlos zur Verfügung gestellter Programme auch noch diesen ganze CRA Papierkram zu machen. Da kann man nur dabei verlieren, denn das ganze ist ohne Anwalt ein Fettnapf an Fettnapf in das man reinlaufen kann. Auch ich werden einige meiner Programme nicht mehr zur Verfügung stellen.

Als Alternative kann man natürlich aus Europa auswandern, dann ist man aus dem ganzen EU Recht draußen.