Hallo,
ich suche nach Anregungen um folgendes zu implementieren:
Ein Kunde möchte Messwerte, Datum und Uhrzeit auf einem Gerät
gespeichert haben. Das Gerät meldet sich als USB Massenspeicher am PC
an. Dort sollen dann für jede Messung eine Datei liegen, welche vom
Benutzer nicht, bzw. nur schwierig veränderbar ist (ähnlich wie ein PDF
zum Beispiel).
Da es sich um einen Mikrokontroller mit max. 1MB Flash handelt und es
natürlich super wäre, wenn wir den internen Flash ohne zusätzlichen
externen Speicher nutzen wollen, käme dann zusätzlich ein Platzproblem
dazu.
Das Platzproblem ist aber nicht so wichtig, da ein externer Speicher
schon möglich wäre, wenn es sein muss.
D.h. der Mikrokontroller muss mit wenig Aufwand eine Datei erzeugen, die
der Benutzer zwar lesen kann, aber nichts daran ändern kann.
Ich bin gespannt, was euch für Lösungen einfallen (ich verrate meine
jetzigen Lösungen erst einmal nicht, um die Diskussion anzuregen).
Schönen Gruß,
Johannes
Johannes schrieb:> D.h. der Mikrokontroller muss mit wenig Aufwand eine Datei erzeugen, die> der Benutzer zwar lesen kann, aber nichts daran ändern kann.
Wo soll das Problem sein?
Da du die Controllerseite implementierst, steht es dir doch völlig
frei, sämtliche Schreibzugriffe von der USB-Seite einfach
abzulehnen. Als äußeres Kennzeichen kannst du ja die Datei auch
als "schreibgeschützt" anzeigen lassen (im Verzeichniseintrag).
Wenn du das ordentlich machst, kannst du auch gleich das ganze
Medium als schreibgeschützt deklarieren, dann wird das Betriebssystem
gezwungen, es read/only einzugliedern und von sich aus drauf zu
verzichten, überhaupt Schreibzugriffe darauf vorzunehmen.
Was ist denn der Sinn davon? Du kannst einfach die Daten binär
rausschreiben in irgendeinem kryptischen Format, und dann einen kleinen
Viewer programmieren.
Jens schrieb:> Du kannst einfach die Daten binär> rausschreiben in irgendeinem kryptischen Format
"security by obscurity" ist kein Konzept. Zumindest keins, das auch
funktioniert.
Jörg Wunsch schrieb:> "security by obscurity" ist kein Konzept. Zumindest keins, das auch> funktioniert.
Die Frage ist doch, was der Anwendungszweck genau ist. Wenn es
verhindern soll, dass irgendwelche Studenten die Daten schönen dann wird
es reichen. Wenn es irgendwelche Daten bei einem militärischen
Feldversuch aufnehmen soll, dann wohl nicht ;-)
Jens schrieb:> dann wird> es reichen.
Gemessen daran, dass der Aufwand für eine ordentliche Lösung auch
nicht größer ist, sehe ich keinen Grund, warum man mit diesem
Argument eine solche Krücke implementieren möchte.
Hallo,
hier noch ein paar Hintergrundinfos:
Der Anwender soll keine Software installieren müssen, da sich das Gerät
um ein medizinisches Gerät handelt und die Software dann auch
zertifiziert werden muss, was verhindert werden soll.
Dennoch sollen die Anwender die Daten nicht ohne weiteres verändern
können, da die Daten als Nachweis für die Krankenkasse dienen sollen.
Wenn jetzt jemand aber mutwillig (mit etwas Aufwand verbunden und
"aktiv") die Daten verändert, dann ist es egal.
Schönen Gruß,
Johannes
Für die LPC Serie von NXP gibt es im Netz so einige Demos, dann verhält
sich der Controller nach außen als USB Stick. Google mal nach folgender
Kombination: lpc mass storage usb
Johannes schrieb:> mir geht es in erster Linie darum, wie (in welchem Format) ich die Daten> ablege, sodass sie nicht veränderbar sind.
Das Format ist doch völlig egal, wenn der Mikrocontroller über USB nur
Lesezugriffe auf die Daten zulässt. Das hat Jörg doch bereits
geschrieben. Liest Du überhaupt die Antworten?
J.-u. G. schrieb:> Das Format ist doch völlig egal, wenn der Mikrocontroller über USB nur> Lesezugriffe auf die Daten zulässt.
Falls es natürlich um eine Manipulationssicherheit der Daten auch
nach dem Lesen vom Controller geht, dann wäre wohl ein
verschlüsseltes PDF (bei dem das Leserecht freigegeben wird) die
erste Wahl. Dann gehört das Thema aber eher in die PC-Programmierung.
Doch, ich lese eigentlich schon die Antworten.
Es ist nur folgendermaßen:
Angenommen, das Gerät ist read-only. Dann macht der Benutzer die Datei
auf und speichert als Dokumentation diese lokal. Diese Datei ist dann
nicht mehr read-only und auch nicht mehr schreibgeschützt, je nach
Betriebssystem. Und genau die lokale Datei soll eben nicht veränderbar
sein, da die Datei auf dem Gerät nach dem Auslesen gelöscht werden kann
(bzw. muss um Platz für neue Messungen zu schaffen).
Ich kläre gerade mit dem Notified Body (der Zulassungsstelle), ob eine
schreibgeschützte Datei als Manipulationsschutz ausreicht (deswegen auch
noch kein Kommentar zur Antwort von Jörg).
Schönen Gruß,
Johannes
Verschlüsseltes PDF wäre eben übers Ziel hinausgeschossen und auf jeden
Fall PC-Software.
Ich hatte eigentlich bisher an ein Bild (bmp oder ähnliches gedacht).
PDF auf dem Kontroller zu erzeugen ist wohl zu extrem und steht in
keiner Relation zum Aufwand.
Johannes schrieb:> Verschlüsseltes PDF wäre eben übers Ziel hinausgeschossen und auf jeden> Fall PC-Software.
Inwiefern? Einen Acroread wirst du doch wohl voraussetzen können.
> Ich hatte eigentlich bisher an ein Bild (bmp oder ähnliches gedacht).
Damit wirst du das vergessen können.
> PDF auf dem Kontroller zu erzeugen ist wohl zu extrem ...
Warum? So schlimm kann das nicht sein, du wirst ja nicht nur einen
ATtiny45 benutzen wollen.
Johannes schrieb:> Es ist nur folgendermaßen:> Angenommen, das Gerät ist read-only. Dann macht der Benutzer die Datei> auf und speichert als Dokumentation diese lokal. Diese Datei ist dann> nicht mehr read-only und auch nicht mehr schreibgeschützt, je nach> Betriebssystem. Und genau die lokale Datei soll eben nicht veränderbar> sein, da die Datei auf dem Gerät nach dem Auslesen gelöscht werden kann> (bzw. muss um Platz für neue Messungen zu schaffen).
das ist aber etwas komplett anderes als du oben geschrieben hattest.
Dafür gibt es nur eine saubere Lösung, die erzeugt eine Signatur für
diese Datei - damit kann geprüft werden ob der Inhalt geändert wurde.
Naja, es soll schon ein ARM-CortexM3 sein.
Gibt es denn eine PDF-Erzeuge-Bib für Kontroller? Wenn dies ohne
Probleme machbar ist, wäre es natürlich super. Kennt sich jemand damit
aus?
Warum soll ich die Lösung eine Bilddatei zu erzeugen vergessen? Für mich
ist das ähnlich wie ein PDF, oder?
Johannes schrieb:> Warum soll ich die Lösung eine Bilddatei zu erzeugen vergessen? Für mich> ist das ähnlich wie ein PDF, oder?
warum sollte man das Bild nicht bearbeiten könnnen? Auch ein PDF kann
man mit Entsprechende tools bearbeiten.
Es hilft nur eine Signatur mit der du die bearbeitung nachweise kannst,
dann ist es egal ob es ein Bild PDF oder eine Textdatei ist.
Naja, ein Bild mit Wasserzeichen wäre wohl möglich. Wenn aber mit den
Daten auf dem PC weiter gerechnet werden soll, ist das nicht so
praktisch.
In JPGs kann man auch nach dem Ende der Bilddaten noch jede Menge Krams
speichern.
Matthias Sch. schrieb:> Naja, ein Bild mit Wasserzeichen wäre wohl möglich.
ein wasserzeichen dient aber nur zu Erkennung der herkunft, nicht um zu
erkennen ob etwas manipuliert wurden ist.
Johannes schrieb:> Für mich> ist das ähnlich wie ein PDF, oder?
Bei PDF sind die entsprechenden Dinge (Signatur bzw. Verschlüsselung)
bereits definiert, du musst sie also nur noch anwenden.
Danach gugeln kannst du selbst. Eine Bibliothek muss ja nicht
explizit für einen Microcontroller geschrieben worden sein,
insbesondere, da du beabsichtigst, einen 32-bit-Controller zu
benutzen und damit einiges an Code ziemlich direkt benutzen kannst,
der für 32-bit-PCs konzipiert worden ist. Es gibt eine Reihe an
Opensource-Tools, die PDF erzeugen können, das solltest du dir also
einfach mal ansehen.
Jörg Wunsch schrieb:> Bei PDF sind die entsprechenden Dinge (Signatur bzw. Verschlüsselung)> bereits definiert, du musst sie also nur noch anwenden.
Mann kann doch auch schlichten Text signieren, wie bei EMails.
Gruss Reinhard
Reinhard Kern schrieb:> Mann kann doch auch schlichten Text signieren, wie bei EMails.
Das kann man zwar, aber da zum Lesen und Verändern einer Textdatei jeder
beliebige Editor verwendet werden kann, der sich nicht für die
"Signatur" interessiert, bringt das nicht viel. Es kann nur nachträglich
festgestellt werden, daß verändert wurde, aber dann schwimmt das Kind
ja schon im Brunnen.
Eine passwortgeschützte PDF-Datei ist da überlegen, da das Bearbeiten
der Datei eben nur bei Bekanntsein des Passwortes möglich ist.
Rufus Τ. Firefly schrieb:> Eine passwortgeschützte PDF-Datei ist da überlegen
Das Problem ist, dass der Passwort-Schreibschutz eine Sache der
Konvention ist. Nur Verschlüsselung und Signierung sind davon
unabhängig, ob sich jemand dran hält, deshalb hat man ja soviel
Entwicklungsaufwand reingesteckt.
Irgendwo muss es ja eine Software geben, die die Daten auswertet - eben
diese müsste auf eine gültige Signatur prüfen.
Meines Wissens sieht das das Finanzamt ähnlich. Ich lasse jeden Monat
die Sigantur der 1&1-Rechnung prüfen, damit es keinen Ärger gibt.
Gruss Reinhard
Reinhard Kern schrieb:> . Nur Verschlüsselung und Signierung sind davon> unabhängig, ob sich jemand dran hält, deshalb hat man ja soviel> Entwicklungsaufwand reingesteckt.
richtig, aber er will ja das die Daten lesbar sind - da macht
verschlüsselung keinen Sinn. Man muss nur signieren.
Hi,
wenn du ohne sw installation auskommen musst, kannst du ja einen eigenen
viewer (exe) mit auf den read-only speicher legen. Dann die dateien noch
verschlüssen und signieren.
Aber am Ende wirst du nix finden was 100% sicher ist.
Auch PDFs kann man zb per screenshot kopieren, durch einen OCR schicken,
bearbeiten und wieder ein PDF draus machen
gruß
heinz
heinz schrieb:> Auch PDFs kann man zb per screenshot kopieren, durch einen OCR schicken,> bearbeiten und wieder ein PDF draus machen
Oder einfach mit Libre Office Draw öffnen und bearbeiten.
Wie wäre es denn in der Datei noch eine Prüfsumme einzufügen, die in
einer nur dir bekannten Art einfach alle Daten in verschlüsselter Form
nochmal enthält?
Sagen wir einfach mal du würfelst die Bits der Ergebnisse etwas
durcheinander und invertierst sie teilweise. Dann setzt du am besten
noch Checksummen dazu und am Ende nimmst du wenn möglich auch ein paar
verschiedene Verfahren die einfach im µC wild gewechselt werden und
durch bestimmte Bitfolgen im Ergebniss für dich ersichtlich sind.
Solange niemand genau weiß wie die Daten in diesem Format gespeichert
sind ist es auch manipulationssicher. Denn wenn man es manipulieren
würde wären die Checksummen nicht mehr in Ordnung und außerdem wüsste ja
keiner welcher Wert wofür steht. Das man das natürlich knacken kann ist
klar aber du meintest ja was von vertretbarem Aufwand.
Bsp:
a1 a2 a3 a4 -> Daten A
b1 b2 b3 b4 -> Daten B
Dann für beide ne Checksumme z.b. die Anzahl der enthaltenen 1er.
! stellt invertierung dar.
() soll heißen das es am ende nur ein Bit sein soll.
Danach baut man daraus z.b. a3 b2 (a1 + b4) !b4 ca1 !b1 b3 !ca2 cb2 cb1
a2 !(a4 + a3) cb3 !ca3 1010 <- art der Anordnung z.b.
Dann könntest du z.b. noch ne CRC über das ganze bilden und das auch
noch anfügen bzw mit einwürfeln. Statt binär gibst du es dann noch in
Hex an oder Oktal so und schon kommt keiner mehr drauf was da wofür
steht ohne das er sehr lange drann sitzt und das Gerät manipuliert um
z.b. die Reaktion auf verschiedene Eingabesequenzen zu ermitteln. Um da
noch Verwirrung zu stiften könntest du einfach ein paar dummy Bits
einstreuen die zufallsgeneriert sind und in der Rekonstruktion ignoriert
werden.
Und du kannst am Ende ganz leicht feststellen ob das ne Orginaldatei ist
indem du es wieder entschlüsselst und mit dem lesbaren Inhalt der Datei
gegenprüfst.
Nachteil ist halt man muss der Datei misstrauen und sie prüfen.
D.h. es ist nicht manipulationssicher aber es lässt sich sagen ob die
Datei manipuliert wurde und sogar der orginale Inhalt wieder herstellen,
falls nicht auch jemand das Codewort angerührt hat. In diesem Fall ist
halt nur feststellbar das die Angaben manipuliert sind.
Ich bitte darum Schreibfehler einfach zu ignorieren, da ich grade zu
müde bin, um das alles nochmal genau durchzulesen.
Gruß Andreas
Johannes schrieb:> Hallo Andreas,> das ist mal ein gute Antwort.> Die Lösung finde ich super. Genau so etwas habe ich gesucht.> Viel Dank!
schön, hier habt nur gerade die Signatur neu erfunden. Warum nicht etwas
nehmen was standardiesert ist als sich etwas selber einfallen zu lassen
und dabei eventuell noch fehler machen?
Eine Signatur ist ein unterschrieben Hash.
Das könnte man sogar mit einer beliebigen software prüfen. Dafür müsste
man allerdingt die Signatur in einer extra Datei speichern. (*.p7s)
Und für einen 32bit µC sollte das kein Problem sein.
Peter II schrieb:> schön, hier habt nur gerade die Signatur neu erfunden.
Auf die Klassische fehlerbehaftete Weise
http://de.wikipedia.org/wiki/Security_through_obscurity
Was macht man übrigens wenn der User einfach den "Datenmüll" löscht? Ich
denke auch das das einzige Ziel sein sollte die Unversehrtheit der Daten
zu gewährleisten, ein Manipulieren durch welches die Daten zerstört
werden ist immer möglich, es geht doch nur darum später beweisen zu
können: Ja die Daten kamen genau so aus dem Gerät heraus.
Hi,
ich habe exakt sowas programmiert, für einen PIC18. Der interne Flash
wurde genutzt, das gerät hat sich als Massenspeicher angemeldet.
Da du ja offenbar das Gerät selbst baust, hats du ja sicherlich Zugriff
auf den Sourcecode für den USB Stack und das interne Dateisystem.
Ich habe es damals so gemacht, dass das USB Interface bei
Schreibzugriffen auf den Speicher nichts gemacht hat, das Device hat
sich vorher einfach als schreibgeschützt im Windows angemeldet. Das
klappte sehr gut.
Hans W. schrieb:> Ich habe es damals so gemacht, dass das USB Interface bei> Schreibzugriffen auf den Speicher nichts gemacht hat, das Device hat> sich vorher einfach als schreibgeschützt im Windows angemeldet.
Hatten wir oben schon durch. Hilft nichts, da auch eine zumindest
Manipulationserkennung jenseits des USB-Massenspeichers möglich
sein soll (wie wir nun wissen).
Darum geht es hier nicht, hier sollen manipulationsgeschützte Dateien
erzeugt werden -- die also auch nach dem Kopieren auf einen PC nicht
verändert werden können.
Johannes schrieb:> Der Anwender soll keine Software installieren müssen, da sich das Gerät> um ein medizinisches Gerät handelt und die Software dann auch> zertifiziert werden muss, was verhindert werden soll.> Dennoch sollen die Anwender die Daten nicht ohne weiteres verändern> können, da die Daten als Nachweis für die Krankenkasse dienen sollen.
Mir wird Angst und Bange, wenn Leute mit so wenig Knowhow, ich bin
geneigt zu sagen: Bastler, solche Anwendungen programmieren, bei denen
sehr persönliche Daten (medizinisches Gerät) und später wichtige
Entscheidungen (Kontrolle durch Krankenkasse) dranhängen.
... und diese Leute dann in einem Bastlerforum nach der Lösung fragen,
wird mir noch banger.
>Darum geht es hier nicht, hier sollen manipulationsgeschützte Dateien>erzeugt werden -- die also auch nach dem Kopieren auf einen PC nicht>verändert werden können.
Ach so, das hatte ich dann flasch verstanden / überlesen. Dann macht
mein Ansatz natürlich keinen Sinn.
Da hilft dann wahrscheinlich nur ein Kyrpto-Ansatz...
Patient schrieb:>> Mir wird Angst und Bange, wenn Leute mit so wenig Knowhow, ich bin> geneigt zu sagen: Bastler, solche Anwendungen programmieren, bei denen> sehr persönliche Daten (medizinisches Gerät) und später wichtige> Entscheidungen (Kontrolle durch Krankenkasse) dranhängen.>>> ... und diese Leute dann in einem Bastlerforum nach der Lösung fragen,> wird mir noch banger.
Diese Befürchtung relativiert sich.
Fast täglich melden die Zeitungen welch hoher Nutzen für die
Allgemeinheit in der Ausführung solcher Tätigkeiten durch vermeintlich
Professionelle besteht.
Adobe, Microsoft und Konsorten sind mal als Beispiele angeführt.
Dann doch lieber ein Bastler der sich hinter sein Projekt klemmt, als
ein professioneller Programmierer der als erstes gelernt hat wie man
seine Fehler vertuscht und leugnet.
Dennis Heynlein schrieb:> Patient schrieb:>>>> Mir wird Angst und Bange, wenn Leute mit so wenig Knowhow, ich bin>> geneigt zu sagen: Bastler, solche Anwendungen programmieren, bei denen>> sehr persönliche Daten (medizinisches Gerät) und später wichtige>> Entscheidungen (Kontrolle durch Krankenkasse) dranhängen.>>>>>> ... und diese Leute dann in einem Bastlerforum nach der Lösung fragen,>> wird mir noch banger.>> Diese Befürchtung relativiert sich.> Fast täglich melden die Zeitungen welch hoher Nutzen für die> Allgemeinheit in der Ausführung solcher Tätigkeiten durch vermeintlich> Professionelle besteht.> Adobe, Microsoft und Konsorten sind mal als Beispiele angeführt.> Dann doch lieber ein Bastler der sich hinter sein Projekt klemmt, als> ein professioneller Programmierer der als erstes gelernt hat wie man> seine Fehler vertuscht und leugnet.
Nein! Der Patient hat vollkommen Recht!
Hier relativiert sich leider rein gar nichts!
Es ist doch kaum zu übersehen, dass der TO auch ein so genannter
"Professioneller" ist, der für seinen Kunden was zusammenschwurbeln
soll.
Und er ist auch nicht besser als der von dir angesprochene vertuschende
Programmierer. (Sofern man da irgendwelche Maßstäbe anlegen möchte.)
Denn:
1. sucht er hier Anregungen,
2. hält er seine eigenen Ideen zurück (sofern er denn auch welche
hatte),
3. kommt er mit für das Problem wesentlichen und relevanten
Informationen erst im Nachgang, so dass die von anderen Usern geleistete
Arbeit hinfällig ist,
4. nimmt keine konstruktiven Vorschläge an,
5. begeistert sich für Gefrickel a la "Security by Obscurity".
6. wird der TO wohl auch vertuschen, wo er seine Lösung her hat. Ich
glaube ehrlich gesagt kaum, dass auf seinem Produkt "Mit freundlicher
Unterstützung der User von mikrocontroller.net" stehen wird.
Hab ich noch was vergessen?
Michael
PS: Sorry, wenn ich grad etwas intolerant rüberkomme. Aber ich bin bei
derartigen Anfragen fast genau so wenig "amused", wie wenn das Forum mit
Hausaufgaben.de oder Studiennachhilfe-für-Faulpelze.de verwechselt wird.
ergoproxy schrieb:> Wie wäre es denn in der Datei noch eine Prüfsumme einzufügen, die in> einer nur dir bekannten Art einfach alle Daten in verschlüsselter Form> nochmal enthält?
also dann sollte man doch lieber sichere kryptographische Algorithmen
nutzen. Du könntest z.B. mit ECDSA (das läuft sogar auf 8-bit
Microcontrollern recht performant) eine Signatur erzeugen und diese
später auch überprüfen. Den Schlüssel für die Erzeugung der Signatur
liegt dabei nur in deinem auslesegeschützten Microcontroller. Wenn es
noch sicherer sein soll dann nimmst du gleich einen zusätzlichen
Kryptochip mit sicherem Schlüsselspeicher. Dann erhälst du ein sehr
hohes Sicherheitsniveau. Aber auch ein nicht sicherer Schlüsselspeicher
auf einem Standard-Microcontroller zusammen mit einem sicheren
Algorithmus ist wohl besser, als selber einen (ganz ganz erheblich!)
unsicheren Algorithmus zu schaffen.
Denkbar wäre sonst auch der Einsatz eines sicheren Microcontrollers.
Dann dürftest du dich schon irgendwo auf dem Sicherheitsniveau von
Smartcards bewegen. Ein externer Kryptochip bietet immer noch die
Möglichkeit, den unsicheren Microcontroller oder gar die Kommunikation
zwischen Microcontroller und Kryptochip anzugreifen (wobei es auch hier
Secure Channel Protokolle gibt ...).
Gruß
Stephan
noch als Ergänzung:
Aber bitte kein eigenes Durcheinanderwürfeln von Bits und dann noch die
Nutzung von CRC als Signaturersatz. Ich behaupte einfach mal, dass dein
eigener Algorithmus jede Menge Kollisionen aufweisen wird. Auch bedeutet
ein solch symmetrischer Ansatz auch, dass dein "Geheimnis" auch in der
Software enthalten sein muss, die die Signaturen überprüft. Ein
Computerprogramm ist sicher erstmal einfacher zu analysieren, als ein
lesegeschützter Microcontroller.
Der Implementierungsaufwand für sicheres Signaturverfahren zu nutzen ist
kaum größer. Es gibt ja auch durchaus fertige Bibliotheken ...
Wäre es nicht zweckmäßiger, für die Datenverarbeitung eine Datei mit
AES-Verschlüsselung und Signatur zu erzeugen und für den Benutzer zur
Selbstkontrolle eine Klartext-Datei? Damit hat man verifizierbare Daten
für den Auftraggeber und eine Informationsmöglichkeit für den einfachen
Benutzer.
_.-=: MFG :=-._
Ich denke es handelt sich nicht um eine Hochsicherheitsanwendung ;)
Vermutlich ist es ein Gerät, das von der Krankenkasse ausgeliehen wird
und dafür der Nachweis zu erbringen ist, das es auch benutzt wurde.
Markus hat das vorgeschlagen, was ich auch tun würde. Der Patient kann
sich die unverschlüsselten Daten in jedem Editor anzeigen lassen und die
Krankemkasse bekommt ein Programm, das die verschlüsselten Daten als
Statistik ausgibt und alle Daten amschliessend für den nächsten
Patienten löschen kann. Der Sachbearbeiter der Krankenkasse hat sicher
besseres zu tun als sich durch Listen zu wühlen.
Das sind aber alles nur Vermutungen !
Wer ist dein Kunde ?
Gerätehersteller, Arzt, Patient, Krankenkasse.
Wer ist der Anwender ?
Arzt, Labor, Krankenhaus, Patient
In welche Länder soll das Gerät verkauft werden ?
usw ....
Markus ---- schrieb:> Wäre es nicht zweckmäßiger, für die Datenverarbeitung eine Datei mit> AES-Verschlüsselung und Signatur zu erzeugen und für den Benutzer zur> Selbstkontrolle eine Klartext-Datei?
und wozu die veschlüsselung? Eine Signatur kann man ohne verschlüsselung
machen.
Hans-georg Lehnard schrieb:> Ich denke es handelt sich nicht um eine Hochsicherheitsanwendung ;)
aber warum einen unsicheren Algorithmus selber bauen, wenn es sichere
Algorithmen bereits fertig implementiert gibt ;) . Man muss es ja auch
nicht unnötig unsicher gestalten.
Genauso würde ich bei einer Verschlüsselung niemand zu irgendeinem
Eigenbaualgorithmus raten. Egal wie sicher die Anwendung sein muss: AES
wird immer die bessere Option sein ;)
Hans-georg Lehnard schrieb:> Vermutlich ist es ein Gerät, das von der Krankenkasse ausgeliehen wird> und dafür der Nachweis zu erbringen ist, das es auch benutzt wurde.
Dann könnte man die Daten im Gerät speichern und die KK würde es
auslesen können, wenn sie das Gerät zurück erhält.
Gruß
Jobst
Datei erzeugen, SHA1- und MD5-Hash erzeugen und mit nem
Public-Private-Keyverfahren verschlüsseln, an die Datei anhängen und
fertig ist eine gebrauchbare Signatur.
