Hallo Community, ich arbeite mich gerade in die mC- Programmierung ein. Ich möchte ein Datenloggerprogramm erstellen, welches mir bestimmte Daten auf eine mikro SD speichert. Mit der SPI Schnittstelle klappt das ja ganz gut, soweit ich das verstanden habe. Allerdings verstehe ich nicht ganz wie die SD Karte die Daten ablegt. Ich habe bereits sämtliche Artikel zu SD Karten u.ä. gelesen aber irgendwie stehe ich auf dem Schlauch. Ich muss der Karte doch eine Adresse oder sowas übergeben, damit sie weiß wo die Daten abgelegt werden sollen?! Wie sieht die z.B. Adresse aus? Zudem besitzen SD Karten ja mehrere Blöcke die um die 512 Byte groß sind. Und wenn ich nun z.B. nur ein 2 Byte großes Datenpacket speichern möchte, was ist dann mit den "restlichen 510" Byte? Hoffe ihr könnt mir weiter helfen. Viele Grüße Marco
Marco Reiner schrieb: > Und wenn ich nun z.B. nur ein 2 Byte großes Datenpacket speichern > möchte, was ist dann mit den "restlichen 510" Byte? geht nicht. Du musst immer 512byte übertragen.
@ Marco Reiner (marco_re) >Zudem besitzen SD Karten ja mehrere Blöcke die um die 512 Byte groß >sind. Es sind EXAKT 512 Byte. > Und wenn ich nun z.B. nur ein 2 Byte großes Datenpacket speichern > möchte, was ist dann mit den "restlichen 510" Byte? Die muss man auch beschreiben. Lange Rede, kurzer Sinn. Vergiss das Beschreiben "zu Fuss", nimm eine der vielen Bibliotheken, welche sich um die Dateiverwaltung kümmern (FAT). Dann kannst du ganz einfach und bequem Dateien auf die SD-Karte schreiben und lesen, und auch am PC. Siehe MMC- und SD-Karten. Ich kann die Lib von Meister ELM Chan empfehlen, die funktioniert prima! http://elm-chan.org/fsw/ff/00index_e.html
Danke für eure Antworten. Die Daten sollten nicht für jedermann via Plug n Play am PC auslesbar sein, daher würde ich die gern die Daten ohne eine Verwaltungssystem abspeichern. Oder kennt ihr brauchbare alternativen zwecks "Verschlüsselung"? Ich habe leider noch keinen passenden Artikel zu SD Karten gefunden, wo der Speichervorgang konkret beschrieben wird, würde mich freuen wenn jemand von euch etwas passendes zum durchlesen hat. Grüße Marco
Wenn du keine Verwaltungsinformationen haben willst - nimm einfach den unteren Layer einer SD-Library. Die haben alle zwei Schichten, Filesystem und SD-Karten-Zugriff. Artikel über den Zugriff? Die beste konkrete Beschreibung ist der Programmcode. Initialisierung der Karte ist recht komplex. Historisch gewachsen gibt es da zig Varianten, die das Programm durchprobiert. Dann kommt nicht mehr viel: 512Byte-Block schreiben und lesen. Da gibt es auch 2 Varianten. Wenn du dich da einarbeitest, bekommst du Schreikrämpfe und bist froh, dass andere Leute schon fertige Libraries zusammengestellt haben.
Ok super das hört sich doch brauchbar an! Danke ich werd mich da mal reinlesen. Grüße Marco
Wenn du nur 2 Bytes beschrieben willst, musst du 1) Einen 512-Byte Block in ein Array einlesen 2) Zwei Bytes davon verändern 3) Den Block zurück auf die Karte schreiben Achtung: Jeder Schreibzugriff reduziert die Lebensdauer der Karte. Wenn du fortlaufen 2 Bytes schreibst, hast du in 256 Schreibzugriffe pro Block. In dem Fall ist es besser, die Daten erstmal in einem Puffer zu sammeln und erst zum Schluss auf die Karte zu schreiben, wenn der Block komplett ist. Ich komme mit der AVRFAT32 Library gut zurecht: http://www.mikrocontroller.net/articles/AVR_FAT32 In deinem Fall würdest du die Dateien file.c und fat.c einfach weglassen. Du arbeitest mit der mmc.c, die den Zugriff auf Blochebene macht. Der Dateiname täuscht, die Datei ist auch für SD und SD-HC Karten. Du brauchst diese Funktionen:
1 | // prototypen |
2 | extern uint8_t mmc_init(void); // initialisiert die pins und geschwindigkeit |
3 | extern uint8_t mmc_read_sector (uint32_t addr,uint8_t *Buffer); // liest einen sektor mit adresse addr auf Buffer |
4 | extern uint8_t mmc_write_sector (uint32_t addr,uint8_t *Buffer); // schreibt einen sektor mit der adresse addr aus dem puffer Buffer, auf die karte |
Compact Flash Karten im True IDE Mode sind von der Ansteuerung her sehr simpel und einheitlich. Die Karten, Stecker und Controller Chips sind tendenziell robuster; auch Karten mit SLC-Chips sind gut lieferbar. Wer 14 bis 16 Port-Pins spendieren kann sollte sich das mal anschauen. > Die Daten sollten nicht für jedermann via Plug n Play am PC > auslesbar sein, daher würde ich die gern die Daten ohne eine > Verwaltungssystem abspeichern. Kein Problem, die 512-Byte Blöcke sind einfach durchnummeriert. Ich schreibe eine ganz normale Partitionstabelle mit einer kleinen FAT16-Partition an den Anfang der Karten. Dahinter kommen meine Daten ohne weitere Metadaten. Damit sieht die Karte für den normalen PC-Benutzer wie ein völlig normales Speichermedium aus und Windows bietet nicht an, die Karte zu formatieren. Partitionierungstools zeigen den eigentlichen Datenbereich als frei an. Wenn jemand den Platz formatiert, kommt er auch nicht leichter an deine Daten ran. Man kann auch eine zweite Partition anlegen mit einem seltenen Partitionstyp, dann gibt es keinen "freien" Platz und einfachere Tools verweigern jegliche Formatierung.
Hast du mir ein paar Unterlagen wie man bei der Erstellung der Tabelle vorgeht? Hört sich sehr gut an!
Manche Leute legen eine Datei an, die den gesamten Speicherplatz der Karte belegt. So kann der Mikrcocontroller einfach Blockweise drauf zugreifen, er muss nur wissen, wo genaun der erste Block beginnt. Und diese Startposition, wird sich nicht verändern, solange man die größer der Datei beibehält. Solche Karten kann man besonders unter Windows einfacher weiter verarbeiten, als wenn sie kein Filesystem hätten. Können Scriptsprachen und Java überhaupt ohne Filesystem auf SD Karten zugreifen? Vermutlich nicht.
Stefan Us schrieb: > Können Scriptsprachen > und Java überhaupt ohne Filesystem auf SD Karten zugreifen? Vermutlich > nicht. unter Windows und Linux kann man (mit entsprechenden Rechten) immer auf das RAW-Device zugreifen. Dabei spielt die Programmiersprache kaum eine rolle.
> Hast du mir ein paar Unterlagen wie man bei der > Erstellung der Tabelle vorgeht? Du macht Witze, oder? Stecke die Karte in deinen Rechner. Wenn sie noch keine Partitionstabelle hat, wird Windows dir anbieten, eine anzulegen. Danach kannst du mit dem Partitionsmanager (irgendwo in der Systemsteuerung) die Partition löschen.
Also ich arbeite nun mit ElmChans' FatFS Library und zwar nur mit dem unteren Layer. Wie schon von euch erwähnt habe ich dadurch keine Verwaltungsinformationen und somit kann auch niemand, wenn er die Karte an den PC anschließt irgendwelche Daten erkennen. Mit einem HexEditor und dem notwendigen KnowHow könnte man ja trotzdem meine gespeicherten Daten auslesen und auswerten. Daher brauche ich noch irgendeine Datenmanipulation die mir meine Daten, welche zu 90% aus Int- Arrays bestehen, sozusagen "verschlüsselt". Denkt ihr, dass es ausreicht meine originalen Daten mit einem Faktor zu multiplizieren oder einfach mein Array von hinten angefangen auf die SD Karte zu speichern!? Oder ratet ihr mir zu verschlüsselungsverfahren wie RSA, AES.. etc. Grüße Marco
Marco Reiner schrieb: > Denkt ihr, dass es ausreicht meine originalen Daten mit einem Faktor zu > multiplizieren oder einfach mein Array von hinten angefangen auf die SD > Karte zu speichern!? Oder ratet ihr mir zu verschlüsselungsverfahren wie > RSA, AES.. etc. gegen wen willst die Daten schützen, deine Oma oder die NSA?
@ Marco Reiner (marco_re) >Wie schon von euch erwähnt habe ich dadurch keine >Verwaltungsinformationen und somit kann auch niemand, wenn er die Karte >an den PC anschließt irgendwelche Daten erkennen. Kein 0815 User. >Mit einem HexEditor und dem notwendigen KnowHow könnte man ja trotzdem >meine gespeicherten Daten auslesen und auswerten. Eben. >Daher brauche ich noch irgendeine Datenmanipulation die mir meine Daten, >welche zu 90% aus Int- Arrays bestehen, sozusagen "verschlüsselt". Warum? Sind die sooooo brisant, dass sich da irgendjemand für interessieren könnte? >Denkt ihr, dass es ausreicht meine originalen Daten mit einem Faktor zu >multiplizieren ;-) Diese "Verschlüsselung" ist so trivial, da lachen sogar die Amateure drüber. >oder einfach mein Array von hinten angefangen auf die SD >Karte zu speichern!? Noch so ein Lacher. > Oder ratet ihr mir zu verschlüsselungsverfahren wie >RSA, AES.. etc. Lass den Unsinn, nutze FATFS komplett und kümmere dich lieber um die wichtigen und schönen DInge in deinem Projekt. Grüße Marco
Danke für deine ehrliche Meinung. Das sichere, manipuliersichere abspeichern der Daten ist Teil meiner Aufgabenstellung, daher kann ich das nicht einfach so umgehen/ ausblenden. Das mit dem Faktor ist natürlich sehr trivial, aber wenn man den Faktor nicht kennt wird es denke ich ziemlich schwierig diesen herauszufinden, zumindest wenn der Anwender keine Originalen Daten kennt. Also was hab ich denn für Alternativen? Vlt. doch eine Datei mit den Daten anlegen und die Datei selbst verschlüsseln? und ja die Daten sind sehr brisant und sollten nur für die richtigen Personen auswertbar sein. mfg Marco
Marco Reiner schrieb: > Das mit dem Faktor ist natürlich sehr trivial, aber wenn man den Faktor > nicht kennt wird es denke ich ziemlich schwierig diesen herauszufinden, > zumindest wenn der Anwender keine Originalen Daten kennt. Wenn die 0 eine 0 bleibt, sucht man den sonst kleinsten Wert, und dann beschränkt sich das "raten" meist auf eine Hand voll Werte. - Multiplizieren heißt nämlich auch: mehr benötigter Speicherplatz. Vielleicht wäre es da doch einfacher, einen festen Schlüssel mit 16 Bytes zu nehmen und den Block damit via XOR zu behandeln, solange Daten da sind. Bei vollständigen 0x00 blöcken ist der Schlüssel direkt zu erkennen. Was könnte denn mit Daten passieren, die von einem "Unberechtigten" ausgelesen werden?
@ Marco Reiner (marco_re) >Das sichere, manipuliersichere abspeichern der Daten ist Teil meiner >Aufgabenstellung, daher kann ich das nicht einfach so umgehen/ >ausblenden. Dann mach es wenigsten ansatzweise richtig. Nutze normale FAT Dateien und verpass denen eine Verschlüsselung. AES, DES, oder auch einfachere Verfahren. ABer durch "Verstecken" ohne Dateisystem kriegst du keine Sicherheit, nur Stress. >Das mit dem Faktor ist natürlich sehr trivial, aber wenn man den Faktor >nicht kennt wird es denke ich ziemlich schwierig diesen herauszufinden, >zumindest wenn der Anwender keine Originalen Daten kennt. Du hast keine Ahnung von Chiffrierung ;-) So einen "Code" knacken die Profis in 5 Minuten und trinken nebenbei noch Kaffee. >Also was hab ich denn für Alternativen? Vlt. doch eine Datei mit den >Daten anlegen und die Datei selbst verschlüsseln? Genau.
Die gespeicherten Messwerte sollen im Endeffekt nicht verändert werden können und zum anderen sollte man ohne Hintergrundwissen nicht darauf schließen können um was für Messwerte es sich handelt ( z.B. Spannungen, Stromstärken etc.). Mein Projektleiter möchte gerne eine Art Verschlüsselung haben und am liebsten noch ohne Dateisystem auf der SD Karte arbeiten. Dass scheint allerdings viel zu anspruchsvoll zu sein, daher finde ich das mit dem unteren Layer der LIB sehr interessant. Mithilfe eines weiteren Controllers könnte man die Daten dann wieder auslesen und schön in eine Datei schreiben. Was ist denn der übliche Weg, um seine Daten zugriffssicher abzuspeichern?
27, 9, 33, 90, 15... Was fällt an dieser Zahlenreihe auf??? Der geheime Faktor wird doch wohl nicht die 3 gewesen sein... :-)) 5 und 10 fallen als Faktoren auch aus, also die einzig wirklich streng geheime Faktorzahl ist, glaube ich, die 7! ;-)) Riesengrosse Faktoren sind natürlich erst recht auffällig...
genialererfinder schrieb: > 27, 9, 33, 90, 15... Was fällt an dieser Zahlenreihe auf??? Der geheime > Faktor wird doch wohl nicht die 3 gewesen sein... :-)) > > 5 und 10 fallen als Faktoren auch aus, also die einzig wirklich streng > geheime Faktorzahl ist, glaube ich, die 7! ;-)) > > Riesengrosse Faktoren sind natürlich erst recht auffällig... Ja man könnte ja natürlich auch Gleitkommazahlen nehmen, aber ja es scheint lösbar zu sein
Ja, wie man das KGV einer Zahlenreihe herausfindet wurde schon vor einigen Jahren entdeckt! Alerdings finde ich die Idee, auf ein Standarddateisystem zu verzichten nicht mal so abwegig. Ist zwar nicht bombensicher, aber die Arbeit macht sich einfach kein Mensch! Mein (oder Phillip seiner?) Schlau TV speichert Aufzeichnungen auch in unbekannten Format auf SD karte - glaube es hat sich noch niemand die Mühe gemacht das mal zu auseinander zu tüddeln...
Marco Reiner schrieb: > Das sichere, manipuliersichere abspeichern der Daten ist Teil meiner > Aufgabenstellung, daher kann ich das nicht einfach so umgehen/ > ausblenden. Das schaffst Du aber nicht, wenn dir schon die Grundlagen fehlöen, wie zb die Kenntnis der MMC Spezifikation 4 oder 5, je nachdem was grad aktuell ist. Habe ich durchgearbeitet und mir auch was eigenes damals gemacht. Schwer ist esn nicht, Lohnt aber nicht da schon tausend andere das gemacht haben. https://www.sdcard.org/downloads/pls/simplified_specs/archive/partE1_100.pdf Spec V1.0 Uralt, neue sind kostenpflichtig. Und "sicher" ist PGP, SSL und darauf basierende streamfähige Verfahren, die aber die oberste Schicht bilden, noch über der FAT Verwaltung. Ohne FAt ist eine SD nur eine grosse Anzahl sektoren mit 512 Bytes, die bei 0 anfangen und bis viele Millionen gehen. Verschlüsselung (PGP etc.) Verwaltungslayer (FAT) Bitlayer (Disc I/O) PHY (Hardware) Hier mein Interface: // Globale Prototypen // ----------------------------------- byte mmc_WriteBlock(byte,int16,byte*); // Einen Block aus Buffer einschreiben byte mmc_ReadBlock(byte,int16,byte*); // Einen Block in Buffer einlesen byte mmc_FormatCard(); // Formatiert eine 128MB Karte byte mmc_Format32MB(byte); // Formatiert eine 32MB Bank byte mmc_Reset(); byte mmc_init(); // ----------------------------------- // Interne Verwendung uint8_t mmc_OpenWrite(uint8_t,uint32_t); uint8_t mmc_OpenRead(uint16_t); uint8_t mmc_init(); void mmc_InitSPI(byte); uint8_t mmc_response(byte response); uint8_t mmc_GetResponse(); uint8_t mmc_WhileBusy(); uint8_t mmc_reset(); uint8_t mmc_Wakeup(); void mmc_Reboot(); void mmc_ErrorBlinker(); uint8_t SPIMMC(byte);
@ Marco Reiner (marco_re) >Die gespeicherten Messwerte sollen im Endeffekt nicht verändert werden >können und zum anderen sollte man ohne Hintergrundwissen nicht darauf >schließen können um was für Messwerte es sich handelt ( z.B. Spannungen, >Stromstärken etc.). Dazu gibt es eine Verschlüsselung. >Mein Projektleiter möchte gerne eine Art Verschlüsselung haben Dann mach doch eine, welche den namen verdient. Dazu muss man sich halt mal in die Materie ein wenig einarbeiten. D.h. man muss was zum Thema lesen, was andere, DEUTLICH intelligentere Leute als DU dazu gedacht und herausgefunden haben. >und am >liebsten noch ohne Dateisystem auf der SD Karte arbeiten. Dann ist er ein ein Depp, der nur fricklen kann, anstatt eine solide Lösung anzustreben! > Dass scheint >allerdings viel zu anspruchsvoll zu sein, daher finde ich das mit dem >unteren Layer der LIB sehr interessant. Jaja, man kann sich auch wunderbar mit Nebensächlichkeiten aufhalten, und die EIGENTLICHE Aufgabe total vergessen. >Mithilfe eines weiteren Controllers könnte man die Daten dann wieder >auslesen und schön in eine Datei schreiben. OMG! >Was ist denn der übliche Weg, um seine Daten zugriffssicher >abzuspeichern? Sagte ich das nicht bereits?
@ Marco Reiner (marco_re) >> Riesengrosse Faktoren sind natürlich erst recht auffällig... >Ja man könnte ja natürlich auch Gleitkommazahlen nehmen, aber ja es >scheint lösbar zu sein Unsinn. Du hast nicht die leiseste Ahnung von Verschlüsselung, deine eigenen Ideen sind einfach kindisch und albern. Als murkse weiter so rum oder mach es richtig. Wie das geht, habe ich dir beschrieben.
Wir alle wissen, dass man SD Karten auch ohne FAT verwenden kann. Aber ob das eine gute Idee ist, wage ich stark zu bezweifeln. Das FAT Dateisystem ist Bestandteil der SD Spezifikation. Eine SD Karte ohne FAT Dateisystem zu verwenden, bedeutet, die Hardware zu missbrauchen. In diesem Fall erlischt die Garantie. Ich würde nie ein professionelles Ding konstruieren, welches auf missbrauchte Teile basiert. Sowas könnte man nur unter der Ladentheke verkaufen, aber nicht offiziell mit Produkthaftung und so. Ich benutze mein Auto auch nicht ohne die vorgesehenen Sitze - auch wenn das technisch Problemlos machbar ist. Außerdem löst das die Aufgabe "Sicherheit" keinesfalls. Man schafft Sicherheit nicht durch Verschleierung. Diese Methode ist was für völlige Laien. Gegen Manipulation und Auslesen schützt man Dateien durch asymmetrische Verschlüsselung. Eine leicht anzuwendende Software dazu ist PGP (freilich nicht auf 8bit Mikrocontrollern). Die allerwichtigste Frage ist: Welcher Grad an Sicherheit ist gefordert? Im einfachsten Fall genügt bereits eine Dateiendung, die man nicht per Doppelklick öffnen kann.
Marco Reiner schrieb: > Mein Projektleiter möchte gerne eine Art Verschlüsselung haben und am > liebsten noch ohne Dateisystem auf der SD Karte arbeiten. Dass scheint > allerdings viel zu anspruchsvoll zu sein, daher finde ich das mit dem > unteren Layer der LIB sehr interessant. > > Mithilfe eines weiteren Controllers könnte man die Daten dann wieder > auslesen und schön in eine Datei schreiben. > > > Was ist denn der übliche Weg, um seine Daten zugriffssicher > abzuspeichern? Man nimmt ein anerkannt sicheres Verschlüsselungsverfahren und sorgt für eine sichere Schlüsselverwaltung. Verschlüsselung ist witzlos, wenn man den Schlüssel einfach extrahieren kann. So etwas ist die Arbeit von Cryptographen. Die erzählen Dir, wie es richtig geht. Wenn Du nämlich auch nur einen kleinen Fehler machst, gefährdest Du die Sicherheit Deines Systems. Dein Projektleiter möge sich jemanden mit Ahnung von der Sache holen. Sorry, ist so. Da setzt man keinen Anfänger ran. Für die Verschlüsselung brauchst Du Rechenleistung. Ein AVR reicht nicht. Es gibt Controller mit Hardware-Crypto. Zur SD-Card: Schau mal her, was jede SD Card kann. https://www.sdcard.org/developers/overview/copyright_protection/index.html Diese Informationen sind geheim, und Mitglied in diesem exklusiven Club zu werden ist teuer. Extrem teuer. Unanständig teuer. Keine Ahnung, wie ernst es Euch ist. Aber Du solltest wissen, dass es so etwas gibt, und dass das S in SD für Secure steht. MMC-Karten, die elektrisch und mechanisch sehr ähnlich sind, haben dieses Feature nicht. fchk
Stefan Us schrieb: > Das FAT Dateisystem ist Bestandteil der SD Spezifikation. Eine SD Karte > ohne FAT Dateisystem zu verwenden, bedeutet, die Hardware zu > missbrauchen. In diesem Fall erlischt die Garantie. > > Ich würde nie ein professionelles Ding konstruieren, welches auf > missbrauchte Teile basiert. Sowas könnte man nur unter der Ladentheke > verkaufen, aber nicht offiziell mit Produkthaftung und so. Teil der spec ist auch, wo der mbr und die fat liegen müssen (stichwort allocation unit). Eine sd ist nach der Formatierung mit einem pc ohne spezielle tools auch nicht mehr sd konform. das ist aber mehr eine verfügbarkeitsgeschichte als ein technisches Problem.
@ Frank K. (fchk) >So etwas ist die Arbeit von Cryptographen. Die erzählen Dir, wie es >richtig geht. Wenn Du nämlich auch nur einen kleinen Fehler machst, >gefährdest Du die Sicherheit Deines Systems. >Dein Projektleiter möge sich jemanden mit Ahnung von der Sache holen. >Sorry, ist so. Da setzt man keinen Anfänger ran. Naja, im Prinzip schon, praktisch muss man dennoch fragen, welchen Grad an Verschlüsselung man braucht. Es geht wahrscheinlich nur ein einfache Sachen, die nicht jede Nase einfach so lesen soll und nicht um Top Secret Daten. Da braucht es nicht den TOP Algorthimus. >Für die Verschlüsselung brauchst Du Rechenleistung. Ein AVR reicht >nicht. Es gibt Controller mit Hardware-Crypto. Die ATXmegas haben AES in Hardware drin.
Stefan Us schrieb: > Das FAT Dateisystem ist Bestandteil der SD Spezifikation. Eine SD Karte > ohne FAT Dateisystem zu verwenden, bedeutet, die Hardware zu > missbrauchen. In diesem Fall erlischt die Garantie. Ich frage mich wer solchen Unsinn in die Welt setzt? Weder das eine noch das andere stimmt. Mannomann..... muss ja dann mal meinen Ex Arbeitgeber einformieren, dass er tausende Produkte zurück ruft, wo die SD einfach nur ein riesengroßer Array ist ohne jedes Dateisystem dahinter .... hicks.
Ich stimme stefanus zu, daß man heutzutage eine SD-Karte nur noch mit FAT benutzen sollte. Früher sah das anders aus, aber inzwischen haben die Hersteller gemerkt, daß es echt schwer ist, einen universellen wear-levelling-Algorithmus zu basteln (zumal die diesbezüglichen Ansprüche der Speicherchips ständig steigen), und sich die Aufgabe etwas vereinfacht. Auch sonst ist es einfach bequem, wenn man die aufgezeichneten Daten mal eben schnell im PC lesen kann. Und sei es auch nur, um ein Backup zu haben. Zur Sicherheit/Verschlüsselung sehe ich hier zwei Forderungen: Geheimhaltung (der Angreifer soll die Daten nicht lesen können, obwohl er die SD-Karte lesen kann) und Manipulationsschutz (der Angreifer kann die SD-Karte lesen, schreiben und dem System wieder unterjubeln; der rechtmäßige Benutzer soll den Daten ansehen können, daß sie manipuliert wurden). Geheimhaltung erreicht man durch Verschlüsselung. Am einfachsten ist da ein symmetrischer Algorithmus, z.B. AES oder XTEA. Den sollte man noch mit einem geeigneten Modus kombinieren (CBC oder CFB oder so), damit der Angreifer nicht sieht, wenn sich dieselben Daten wiederholen. Der Nachteil bei symmetrischen Verfahren ist, daß man den Schlüssel hüten muß, weil zum Ver- und Entschlüsseln derselbe benutzt wird. Wenn also die Gefahr besteht, daß dem Angreifer der ganze Datenlogger in die Hände fällt, so daß er Flash und EEPROM auslesen kann, brauchst du was stärkeres. Stärker in diesem Sinn sind asymmetrische Verschlüsselungsverfahren, bei denen also zum Verschlüsseln ein anderer Schlüssel gebraucht wird als zum Entschlüsseln. Leider sind die auch deutlich aufwendiger, was Speicherplatz und Rechenzeit angeht. RSA ist so ein typischer Kandidat: irgendwer hat den in einen AVR gequetscht bekommen, aber bei einer zeitgemäßen Schlüssellänge ist der Prozessor dann eine halbe Stunde nur mit RSA-Rechnen beschäftigt, um einen Datenblock zu verschlüsseln. ECC sollte weniger anspruchsvoll sein, keine Ahnung wie das in der Praxis aussieht. Ich würde beim AVR nach Möglichkeit bei symmetrischen Algorithmen bleiben. Zur Manipulationserkennung muß man die Daten sozusagen "unterschreiben". Dafür gibt es auch wieder asymmetrische und symmetrische Verfahren. Die asymmetrischen basieren wieder auf RSA oder ECC und sind entsprechend aufwendig. Die symmetrischen benötigen als Baustein einen Hashalgorithmus, der meist deutlich aufwendiger ist als eine symmetrische Verschlüsselung, aber nicht so schlimm wie das asymmetrische Zeug. Und dann kann man noch mogeln: an jeden Datensatz eine CRC oder so anhängen, bevor verschlüsselt wird. Wenn die Verschlüsselung gut ist, kann der Angreifer das nicht unbemerkt manipulieren, weil er die Prüfsumme nicht richtig hinbekommt (mit einer gewissen Wahrscheinlichkeit entsprechend der Länge der Prüfsumme). Wenn die Verschlüsselung schlecht bzw. unpassend ist, kann der Angreifer die CRC passend zu seiner Manipulation korrigieren (so geschehen bei WEP), oder die Redundanz des Klartextes zum Knacken der Verschlüsselung ausnutzen.
Stefan Us schrieb: > Wir alle wissen, dass man SD Karten auch ohne FAT verwenden kann. Aber > ob das eine gute Idee ist, wage ich stark zu bezweifeln. Immerhin ist diese Idee im Code von elm chan bereits angelegt. Mit der Option Fast_seek wird eine linktable angelegt, in die mit cmd25 direkt geschrieben wird. Der mögliche Geschwindigkeitszuwachs ist enorm. Leider gibt es zu fast_seek wenig Codebeispiele.
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.