Konzept zum "sicheren" Firmwareupdate - Embedded Linux

Würde mich auch interessieren...

Horst schrieb:
> Der private Schlüssel liegt in einem batteriegepufferten internen RAM
> eines Utility-µC und wird beim Öffnen des Gerätes gelöscht. Das Gehäuse
> ist so gestaltet, dass beim Öffnen Netzteilplatine und CPU-Platine
> getrennt werden und damit die Stromversorgung zum RAM getrennt wird.

Was passiert, wenn die Batterie leer ist?
Service-Techniker? Baugruppe einschicken?

Das ist das, was mir spontan einfällt.

Horst schrieb:
> - Der private Schlüssel liegt in einem batteriegepufferten internen RAM
> eines Utility-µC und wird beim Öffnen des Gerätes gelöscht. Das Gehäuse
> ist so gestaltet, dass beim Öffnen Netzteilplatine und CPU-Platine
> getrennt werden und damit die Stromversorgung zum RAM getrennt wird.

Soll das eine neue Implemtierung von geplanter Obsoleszenz werden?

Das abzusichern dürfte hart sein. Gerade mit Linux, gerade wenn man die 
Möglichkeitt hat Updates einzuspielen. Aber wieso legst DU Wert darauf, 
die Datenbank zu sichern. Wenn der Kunde einen Rechtsbruch begeht und 
die Datenbank irgendwie kopiert ist das doch nicht dein Problem? Wenn du 
deinen eigenen Code schützen möchtest ist das ja noch verständlich.

Wenn du genauere Hilfestellungungen möchtest musst du, meiner Meinung 
nach, sagen wovor du dich genau schützen möchtest. Vor:
- Auslesen der Datenbank?
- Modifikation der Datenbank?
- Auslesen deines Codes?
- Modifikation deines Codes?
- Modifikation des Gerätes?
- "Kopieren" der Datenbank von einem anderen Gerät?
etc.

Außerdem, welche Art von Angreifern hast du im Sinne? Die, die auch mal 
den Flash auslöten und neu beschreiben? Der gelangweilte Kollege, der 
einfach mal das Update vom größeren Modell fahren will? Der Typ, der das 
Rasterelektronenmikroskop von letztens gekauft hat? Die Chinesische 
Mafia? NSA? Die meisten davon dürften nämlich zB von deinem 
Gehäuse-Aufbrech-Schutz nicht viel halten, im Zweifel macht man halt das 
erste Gerät kaputt, spätestens beim Zweiten weiß man dann, wo man ein 
Loch in den Deckel fräsen kann.

Horst schrieb:
> - Der private Schlüssel liegt in einem batteriegepufferten internen RAM
> eines Utility-µC und wird beim Öffnen des Gerätes gelöscht. Das Gehäuse
> ist so gestaltet, dass beim Öffnen Netzteilplatine und CPU-Platine
> getrennt werden und damit die Stromversorgung zum RAM getrennt wird.

krasses Fehldesign. Für einen Angreifer, der sich ein zweites Gerät 
beschafft, simpel zu umgehen. Für einen normalen Anwender, dem der 
Utility-µC wegen irgendetwas (EMV-Störung, Bug) abstürzt, dagegen der 
Totalausfall.

Service skaliert auch nicht, da das Gerät nicht extern wartbar ist 
(außer man gibt doch wieder das know-how raus).

>Weil die Datenbank kostenpflichtig ist (wir kaufen die von einem
>Drittanbieter und müssen pro verkaufter Lizenz Gebühren an diesen
>Anbieter abführen), soll eine Firmware nur auf ein Gerät passen.

Da wird sich die Konkurrenz freuen und Harald
Welte (gpl-violations.org) einen Tipp geben. Bevor ich
Aufwand in ein HW-Schutzkonzept reinstecke, würde ich
halt die 250E in einen juristischen Spezialisten reinstecken.
Aus meiner Sicht waere es heikel, dass sich nur durch blosses
Gehäuseöffnen des neuerworbenen Eigentum eine
Funktionsunfaehigkeit oder -minderung ergibt. Das
einfache Feststellen des Öffnen waere OK (ggf. wegen
der Reduzierung von Gewährleistungsansprüchen).

Wir sind uns einig, dass ein ernsthafter Konkurrent
mehrere Geraete kauft und beim ersten rausbekommt, wie
die "Schutzmechanismen" laufen?

IMHO kannst Du die die Datenbank (weil proprietär, richtig?)
so schützen, bzgl. den Firmware GPL Sachen (Linux+Anpassungen,
Linux Userland) musst Du die tatsaechlichen Quellen rausgeben.

Im Prinzip ist der oben beschriebene Schutzmechanismus
so in pgp/gpg verfügbar(auch im Userland, gpg ist GPL),
in dem gpg-Manual waere Mailadresse durch Seriennummer zu ersetzen.
Das waere fertig und direkt einsetzbar und waere auch
zu empfehlen, da man bei der Implementierung von Kryptosystemen
so viele Fehler machen kann, dass man besser was Fertiges
nimmt.

> Was passiert, wenn die Batterie leer ist?
> Service-Techniker? Baugruppe einschicken?

Es ist vorgesehen, dass zwei CR2032-Knopfzellen über eine 
Schottky-Dual-Diode den Utility-µC speisen, so dass diese einzeln 
nacheinander ausgetauscht werden können. Selbstverständlich gibt es 
rechtzeitig eine Warnung, dass die Batterie nachlässt.

Wir denken über eine mechanische Lösung nach (drehender Deckel etc.), 
bei der es nicht möglich ist, beide Batterien gleichzeitig zu entnehmen.

Wenn das Gerät länger als 5 Jahre in einer Schublade liegt und die 
Batterien vollständig entleert werden, hilft tatsächlich nur 
einschicken. Darauf wird der Kunde in der Anleitung hingewiesen. Wir 
planen nicht, für das Re-Initialisieren mehr als das Porto plus eine 
kleine, nicht mal kostendeckende Aufwandspauschale zu verlangen.

> Soll das eine neue Implemtierung von geplanter Obsoleszenz werden?

Nein. Eine wesentliche Funktion des Gerätes ist es, Daten aufzuzeichnen, 
die "manipulationssicher" sind, d.h. die Hürden für eine Manipulation 
werden mit technischen Maßnahmen erhöht. Dazu gehört es, die Daten mit 
einer digitalen Signatur zu versehen. Das Gerät enthält den privaten 
Schlüssel. Die öffentlichen Schlüssel aller unserer Geräte sind in der 
Auslesesoftware hinterlegt, die wir als Stand-Alone-Programm und als DLL 
für Drittanbieter zur Verfügung stellen.

Dieses Vorgehen ist von der Zulassungsstelle für diese Geräte so 
vorgeschrieben.

Dass die Datenbank mit dem gleichen System geschützt wird, ist sozusagen 
ein Abfallprodukt.

> Wenn du genauere Hilfestellungungen möchtest musst du, meiner Meinung
> nach, sagen wovor du dich genau schützen möchtest. Vor:

> - Auslesen der Datenbank?

Ja. Es soll verhindert werden, dass die Datenbank extrahiert, in ein 
anderes Format konvertiert wird und dann als Torrent im Netz landet. 
Nicht, weil die so hoch geheim ist, sondern weil der Urheber der 
Datenbank das in seinen Lizenzbestimmungen so vorschreibt. Urheber ist 
übrigens der Deutsche Staat, bzw. ein mit hoheitlichen Aufgaben 
beliehenes Unternehmen.

> - Modifikation der Datenbank?

Wäre mir persönlich egal, allerdings hätte der Kunde auch nichts von 
geänderten = falschen Daten.

> - Auslesen deines Codes?

Die Schlüssel sollten nicht ausgelesen werden, die liegen aber auf dem 
Utility µC und werden von diesem verwaltet. Der Programmcode liegt nur 
binär vor und ist nicht so weltbewegend, dass ein Reverse-Engineering 
meine Firma ruinieren würde. Es stecken jedenfalls keine "Trade Secrets" 
drin, wie es immer so schön heißt.

> - Modifikation deines Codes?
> - Modifikation des Gerätes?

Es sollte nicht (bzw. nur mit großem Aufwand) möglich sein, eine 
geänderte Firmware zu installieren, die die privaten Schlüssel ausliest 
und auf dem Bildschirm anzeigt.

> - "Kopieren" der Datenbank von einem anderen Gerät?

Genau das soll verhindert werden, damit ich den Vertrag mit dem Urheber 
der Datenbank einhalte.

> Außerdem, welche Art von Angreifern hast du im Sinne? Die, die auch mal
> [...]
> Mafia? NSA? Die meisten davon dürften nämlich zB von deinem
> Gehäuse-Aufbrech-Schutz nicht viel halten, im Zweifel macht man halt das
> erste Gerät kaputt, spätestens beim Zweiten weiß man dann, wo man ein
> Loch in den Deckel fräsen kann.

Das ist mir klar. Wer ein Gerät kaputt macht, um raubkopierte 
Datenbanken nutzen zu können, handelt nicht wirtschaftlich, da Preis 
Gerät >> Preis Datenbank. Wer das Gerät kaputt macht, um herauszufinden, 
wie er den "RAM-Pufferbatterie-Unterbrechungs-Kontakt" beim nächsten 
Gerät überlisten kann, könnte Aufzeichnungen mit dem Gerät fälschen, die 
dann trotzdem eine valide digitale Signatur hätten. Da es hier aber um 
sportliche Leistungen geht, wäre der maximale Gewinn eine Auszeichnung, 
die man sonst nicht verdient hätte. Und es wäre wahrscheinlich für 
Experten des Sportes eine leichte Sache, gefälschte Daten zu erkennen. 
Das einzige realistische Szenario wäre wohl, die tatsächlich 
stattgefundene Leistung eines anderen für die eigene auszugeben.

> krasses Fehldesign. Für einen Angreifer, der sich ein zweites Gerät
> beschafft, simpel zu umgehen.

Siehe oben.

Wie gesagt, es geht darum, die technischen Hürden so hoch zu machen, 
dass es sich nicht besonders lohnt, diese zu überspringen. Wenn einer 
meiner technisch versierten Kunden die Datenbank doch kopiert, dann kann 
ich es eben auch nicht ändern. Hauptsache, der Prozentanteil dieser 
Nutzer bleibt klein.

> Da wird sich die Konkurrenz freuen und Harald
> Welte (gpl-violations.org) einen Tipp geben.

Warum? Selbstverständlich werden wir alles zur Verfügung stellen, was 
wir zur Verfügung stellen müssen. Und das ist der gesamte Quelltext, 
Konfiguration und Toolchain mit der Ausnahme von

- unser eigener 1st stage Bootloader
- unsere eigene Anwendungssoftware
- Datenbank
- private Schlüssel des individuellen Gerätes
- Firmware des Utility µC

> Aus meiner Sicht waere es heikel, dass sich nur durch blosses
> Gehäuseöffnen des neuerworbenen Eigentum eine
> Funktionsunfaehigkeit oder -minderung ergibt.

Ist leider so vorgeschrieben, wenn wir für das Gerät eine Zulassung 
bekommen wollen, damit es offiziell für die Aufzeichnung dieser 
sportlichen Leistungsdaten eingesetzt werden kann. Das gleiche Problem 
haben sämtliche Konkurrenzprodukte also auch.

> IMHO kannst Du die die Datenbank (weil proprietär, richtig?)
> so schützen, bzgl. den Firmware GPL Sachen (Linux+Anpassungen,
> Linux Userland) musst Du die tatsaechlichen Quellen rausgeben.

Ich gebe selbstverständlich die Quellen etc. für alle verwendete 
GPL-Software heraus, wüsste aber nicht, was gegen eine Auslieferung der 
Firmware als verschlüsseltes Binary spricht?

P.S.: Politisch bin ich übrigens der Meinung, dass diese Datenbank allen 
Bürgern kostenlos zur Verfügung stehen sollte. Die aktuelle Situation 
ist aber eine andere. Da der Nutzerkreis recht eingeschränkt ist, lässt 
man diesen halt für den Aufwand der Datenpflege zahlen.

Wieso muss es dann RAM sein? Nutze doch für den Utility µC einen dieser 
extra sicheren Mikrocontroller mit Lockbits und co. Der spuckt dann 
nicht etwa den Schlüssel an das Linux aus, sondern signiert die Daten 
selber. Also Daten in den Utility µC pumpen und Signatur rausbekommen. 
Das sollte dann sicher genug sein und du hast nicht den Mist mit den 
Batterien.
Auf die Art (nagut, die hatten das in Hardware) hat Sony es geschafft 
die PSP über viele Jahre trotz symmetrischer Krypto (in der Hinsicht) 
sicher zu halten. Jemand, der den Key klauen will müsste dann schon den 
µC aufätzen und mehr.

Bezüglich der Datenbank, hier implementierst du was vorgeschrieben ist, 
zB in eine RAM-Disk decrypten (den Key dafür kann dir ja auch der 
Utility-µC aus dem Header der Datenbank errechnen oder so), aber keinen 
Strich mehr. Ist ja nicht dein Problem wenns dann doch jemand knackt.

Achso um mit der Methode Daten zu fälschen muss man natürlich "nur" den 
Utility-µC selbst ansprechen. Aber ich glaube das fällt in die gleiche 
Kiste wie "ein Gerät kaputt machen um beim nächsten zu wissen wie es 
geht". Du solltest mit dem Utility-µC natürlich auch schon verschlüsselt 
sprechen. Das ist zwar nicht hochsicher da der Key im Code steht, aber 
sollte reichen und ist vor allem auch nicht besser oder schlechter als 
den Key im RAM zu halten.

Ich möchte Dich noch darauf hinweisen, dass es nicht reicht die Sourcen, 
Toolchain und die Konfiguration bereitzustellen um die GPL bzw LGPL zu 
erfüllen. Du musst dem Kunden auch die Möglichkleit geben, eine neue 
Version der unter der GPL/LGPL stehenden Bibliothek zu linken und 
ersetzen. D.h. der Kunde muss irgendwie Zugriff auf das Filesystem 
haben. Siehe GPL Kapitel 6, bzw LGPL Kapitel 4.

Ralph S. schrieb:
> Schutzssysteme .... Der Threadersteller tut mir wirklich leid, dass er
> wohl Anweisungen hat, ein solchiges zu Erstellen !

An sich sind Schutzsysteme einen interessante und wichtige Sache. 
Richtig implementiert (siehe zB. xbox360) stören sie die zahlenden 
Kunden überhaupt nicht, die ungewollten Eindringlinge dagegen werden gut 
abgehalten (zumindest im großen Rahmen).

Um so ein System wirklich sicher zu bekommen muss man natürlich die 
Methoden der Eindringlinge kennen. Ein Firmwarefile von USB/SD zuerst zu 
prüfen und dann bei erfolgter Prüfung in den Flash zu schreiben ist zum 
Beispiel grob fahrlässig. Gut bekannter Angriffsvektor: mofizierter 
Datenträger bietet beim ersten Lesen ein Original-Update, beim zweiten 
Mal ein Custom-Update.
Solche Szenarien gibt es einige, da sollte man sich schon ein wenig 
auskennen.

Linux ist leider auch nicht wirklich für solche Systeme gedacht soweit 
ich weiß. Mir ist keine Methode bekannt, mit Linux eine Chain of Trust 
aufzubauen. Vielleicht wird sich das im Zuge von Secure Boot bessern.

Ansonsten, denk dir n vernünftiges Krypto-Konzept ohne RAM aus, dann 
passt das schon.

> Da es hier aber um
> sportliche Leistungen geht, wäre der maximale Gewinn eine Auszeichnung,
> die man sonst nicht verdient hätte.

Ach her je. Das wird aber kein IGC-Logger? Und die "Datenbank" sind ein 
paar Luftraum-Koordinaten, Wendepunkte etc.?

Frank K. schrieb:
> Oder einfach konsequent keinerlei GPL-Software benutzen. Es gibt ja noch
> mehr als Linux. Für PC-basierte Systeme verwende ich meist OpenBSD. Da
> muss ich nichts rausgeben. Und BSD gibts ja auch embedded, auch wenn das
> weniger verbreitet ist. Oder gleich ein richtiges RTOS.
>
> Frag doch mal die Leute bei WIBU. Die haben auch Dongles in Form von CF-
> und SD-Cards, die gleichzeitig als sicheres Speichermedium dienen
> können. Und sie haben Support nicht nur für Desktop-Systeme, sondern zB
> auch für vxWorks (dem einzigen interplanetaren RTOS).

Genau, pack so vielen proprietaeren scheiss rein wie du nur kannst. Das 
macht das System bestimmt sicherer, einfacher und billiger! Frag doch 
mal bei Microsoft an, die haben Erfahrungen damit Systeme, bei denen 
nicht viel schief gehen kann total in den Sand zu setzen.

Guest (Gast) schrieb:

>Genau, pack so vielen proprietaeren scheiss rein wie du nur kannst.
Propriaetaer muss nicht gleich schlecht sein. Zur GPL gibt es
open_source Alternativen wie BSD-Lizenz.

>Das macht das System bestimmt sicherer, einfacher und billiger!
Das Dogma der Securitybranche lautet (und da bin ich "glaeubig"):
Cheap, simple, secure? Choose two!

>Frag doch mal bei Microsoft an, die haben Erfahrungen damit Systeme,
>bei denen nicht viel schief gehen kann total in den Sand zu setzen.

Die obige sehr sichere Alternative OpenBSD unter BSD-Lizenz wurde
schon erwaehnt, hier muss man den Quellcode/Modifikationen nicht
herausgeben (aber dafuer lt. Lizenz andere Dinge tun).

Wenn man sich fuer Linux entscheidet, ist man an die GPL gebunden.
Das ist fuer viele kommerzielle Produkte und Firmen vollkommen OK,
weil das Basissystem von der Community entwickelt wird und damit
Kosten spart. Die GPL stellt sicher, dass ich z.B. in 5 Jahren
ein GPL  Betriebssystem/Library/Userland mit einer neuen Version,
die mir durch die Community bereitgestellt wird, patchen kann und
darf (bspw. bei sowas wie Heartbleed). IMHO wird das bei den
Internet-of-things-Dingern (und IPv6)
immer wichtiger, weil die dann direkt am Netz haengen werden.
Daher wuerde ich bei einem kommerziellen Produkt auf Linux Basis
erwarten, dass die GPL Sachen (ggf. unter Verlust der
Gewaehrleistung) modifizierbar sind, die Applikation duerfte
durchaus proprietaer sein (muss aber nicht ;-) ).

In dem obigen Beispiel der Verwendung von Linux mit einer
"very-closed" DB darf man durchaus fragen, ob Linux die richtige
Wahl war. Es gibt seit Ende der 90er ein spezielles Urheberrecht
fuer Datenbanken, welches strafbewaehrt illegale Kopien sanktioniert.
Ob das einschlaegig ist und ob hinsichtlich der Liefervertraege
zum DB-Vorlieferanten dieses ausreichend greift, kann nur ein
Jurist klaeren.

Thema Microsoft (SCNR):
1. Keiner ist nutzlos, er kann immer noch als schlechtes
   Beispiel dienen.
2. Viele arbeiten in der (Netzwerk-)Securitybranche,
   die sich nicht entwickelt haette, wenn Microsoft hochsichere
   Systeme designed haette bzw. designen wuerde und daher auch
   Ausloeser fuer die bekannten Alternativen ist/war.
   Hier sage ich nur: Danke Microsoft!

Ich bin mir nicht ganz sicher was diese ganze Lizenzgeschichte an der 
Stelle soll. Zum Einen steht Linux garnicht unter GPLv3 sondern nur 
unter GPLv2. Das heißt, der fragliche Paragraph zum Thema "Neuflashen 
muss möglich sein" steht überhaupt nicht zur Debatte.
Zum Anderen würde es auch kein Problem darstellen, wenn dem nicht so 
wäre. Du integrierst in deinen Bootloader einfach einen Unlock-Befehl. 
Dieser löscht zunächst die Keys aus dem Utility-UC (überschreiben, 
sperren, wie auch immer), dann löscht er den kompletten Flash (außer 
sich selbst natürlich) und zuletzt setzt er die Bootloader-Keys auf 
einen Default-Wert. Nun kann jeder ein eigenes Image flashen. Wenn du 
dazu noch ein Image veröffentlichst, in dem du deinen proprietären Teil 
einfach weglässt/durch Stubs ersetzt dürftest du die GPLv3 erfüllen. Und 
das völlig ohne Nutzen für irgendwelche Angreifer.

Linux und andere GPL-Lizensierte Software sind weit verbreitet und oft 
fast alternativlos, so dass der Einsatz rein von BSD/MIT-Lizensierter 
Software unnötig schwierig ist, zumal das Erfüllen der GPL nun echt kein 
Aufwand ist.

Die Datenbank zu sichern scheint kompliziert, was genau sagt dein 
Vertrag hierzu aus? Mit dem Gedanken im Hinterkopf, dass das 
"Kopierschutz"-Bit auf Audio-CDs eine "wirksame technische 
Kopierschutzmaßnahme" ist, sollte es doch wohl reichen, keinen 
"normalen" Zugang zum System offen zu lassen.

Mich würde vor allem aber interessieren, ob und wie es möglich ist, mit 
einem nicht vertrauenswürdigen System trotzdem vertrauenswürdige 
Signaturen/Daten zu erzeugen. Selbst falls ein (vertrauenswürdiger) 
Utility-UC die Signaturen erzeugt, wie stellt man sicher, dass keine 
gefakten Daten an diesen übergeben werden, ohne den Key dafür wieder im 
RAM stehen zu haben?

Daniel H. schrieb:
> Gar nicht. Man kann lediglich verhindern, dass sich ein nicht
> vertrauenswürdiges System als vertrauenswürdiges System ausgibt, z.B.
> indem man statt einfacher Public-Key-Krypto digitale Zertifikate
> einsetzt, durch welche die Echtheit eines öffentlichen Schlüssels
> verifiziert werden kann. Lässt sich mit diesem Schlüssel dann die
> Authentizität einer Signatur verifizieren so bedeutet dies implizit,
> dass derjenige, der die Signatur erzeugt hat über den zum Zertifikat
> gehörigen privaten Schlüssel verfügt, und somit, da das Zertifikat
> erfolgreich verifiziert wurde, vertrauenswürdig ist.

Das loest nicht sas Problem. Jemand koennte das System weiterhin 
kompromittieren und den legitimen priv key zum signieren verwenden.

Daniel H. schrieb:
> Indem man spezielle Security-Controller einsetzt welche über
> zugriffsgeschützten Speicher verfügen welcher ggf. geschrieben, aber
> nicht ausgelesen werden kann. So verfügen einige Security-Controller
> beispielsweise über Kryptobeschleuniger, welche ihre Schlüssel aus
> dedizierten Registern beziehen. Diese Register können zwar durch den
> Controller geschrieben, aber lediglich durch den Kryptobeschleuniger
> gelesen werden. Allerdings ist auch der Schreibzugriff in der Regel
> reglementiert, so dass man die Schlüssel ohne Berechtigung auch nicht
> ohne Weiteres austauschen kann. Häufig wird das erreicht, indem der
> Controller bereits ab Werk mindestens einen zufällig generierten
> ROM-Schlüssel besitzt, der weder ausgelesen noch überschrieben werden
> kann.

Das ist zwar gut und schoen, jedoch geht es um die Kommunikation mit dem 
Krypto-IC.


Wie auch immer, nach einiger Diskussion ist die einzige Moeglichkeit ein 
solches System sicher zu bekommen die einzelnen Sensorwerte direkt, am 
bestenso frueh wie moeglich, also am besten gleich schon im Sensor zu 
signieren. Das kompromittierte Linux kann dann mit den Werten rechnen 
(lassen), und es ist nachvollziehbar ob die Werte je modifiziert wurden. 
Sprich, das Generieren der Daten muss in einer vertrauenswuerdigen 
Umgebung geschehen, der Rest ist egal.

Daniel H. schrieb:
> Guest schrieb:
>> Jemand koennte das System weiterhin
>> kompromittieren und den legitimen priv key zum signieren verwenden.
>
> Nur wenn das System schlecht designed ist. Ein anspruchsvolleres System
> würde die Funktion zum Signieren nicht ohne weitere Schutzmaßnahmen, wie
> z.B. Challenge-Response-Protokolle, von außen zugreifbar machen.

Das loest das Problem nicht, da der Algorithmus zum Durchfuehren des 
Challenge-Response Protokolls oder Aehnlichem samt Keys auf dem 
vertrauensunwuerdigen Linux Rechners gespeichert werden muss.

Daniel H. schrieb:
> Solange also nicht das vollständige System mit allen Teilnehmern,
> Kommunikationsrichtungen, schützenswerten Daten/Entitäten und vor allem
> Angreifermodellen und Angriffspfaden bekannt ist bringt es wenig sich
> von Sicherheitsfeature zu Sicherheitsfeature zu hangeln.

Es geht doch gerade darum, dass ein potentiell irgendwie 
kompromittiertes System Sensordaten erheben, verarbeiten und 
abspeichern. Dabei soll transparent sein, ob die Daten modifiziert 
wurden.

Das ist im Grunde die Vollstaendige Problembeschreibung, mehr gibts dazu 
nicht zu sagen. Eine Loesung fuer das Problem waere es, die Sensordaten 
direkt im Sensor zu signieren. Beim weiterverarbeiten muessen dann die 
Werte-Signaturen mit gespeichert werden, so dass spaeter nachgerechnet 
werden kann. Da die Sensoren das nicht wirklich von selbst tun werden, 
ist der logische Schritt die Sensordaten in einem vertrauenswuerdigen UC 
einzulesen und dann direkt zu signieren bevor sie an den 
unvertrauenswuerdigen Prozessor gehen. Damit ist die einzige 
Manipulationschance die ein Angreifer hat dadurch gegeben, dass er die 
(analogen?) Sensoreingaenge direkt mit Fake-Daten beaufschlagen muss. 
Laut OP stellt das einen erheblichen Aufwand dar und ist dann anhand der 
Daten trotzdem ersichtlich.

Faellt dir noch eine andere Loesung ein?