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
Hallo, mir geht es in erster Linie darum, wie (in welchem Format) ich die Daten ablege, sodass sie nicht veränderbar sind. Schönen Gruß, Johannes
Du kannst Die Daten z.B mit einer Signatur versehen, dann kann man zumindest zweifelsfrei nachweisen, dass sie verändert wurden.
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
Hallo Andreas, das ist mal ein gute Antwort. Die Lösung finde ich super. Genau so etwas habe ich gesucht. Viel Dank!
Da ist aber eine Signatur wesentlich effektiver. Und sie kann von jedem überprüft werden. Gruß Jobst
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 ;)
Signiere die Files, du musst jedoch den private Key im Controller schützen.
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.
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.