Hallo Forum, ich habe vor, am Wochenende AES mit sagen wir mal 128 Bit Schluessellaenge zu implementieren. Es kam der Vorschlag dass es sinnvoll sein koennte dies fuer einen Mikrocontroller zu tun. Bestuende an soetwas Interesse? Ich find's selber u.U. ganz praktisch. Dann stellt sich nur die Frage nach der Parametrisierung. Sprich: Wie waere es am nuetzlichsten, die Daten in den IC rein und raus zu bekommen? Das Beste waere wohl, die Daten Byteweise einzulesen bis ein Kryptogramm eingelesen wurde, dann verschluesseln und dann wieder auf die selbe Art und Weise ausgeben. Dann muss man aber auch irgendwie den Schluessel da reinbekommen! Aber hei den koennte man ja im Prinzip im EPROM ablegen, solange man den effektiv gegen auslesen schuetzen kann, was ja mit den Lockbits gehen sollte. Man sollte den Schluessel aber irgendwie auch so mal reinbekommen koennen das macht es deutlich flexibler. Hat jemand Vorschlaege wie man das am Besten machen wuerde so dass es gut nutzbar wird? Ein paar Konfigpins zur Auswahl z.B. eines Operationsmodus waere dann auch noch angebracht! Theoretisch muesste man das alles auf nen Mega8 bekommen und ich denk sogar in passabler Geschwindigkeit. Gibt es fertige Kryptochips und was kosten die ueblicherweise? Wenn so nen Chip 10EUR kost koennt sich sowas durchaus lohnen. Ausserdem hab ich im Forum zu AES nur einen Beitrag gefunden. Und NEIN ich will keinen fertigen Code benutzen das ist eine Verstaendnissache. Michael
Hm ich hab noch Tinies daheim die mit 20MHz laufen waere in dem Fall sogar noch besser wuerde ich sagen. Mir fallen ne Menge Anwendungen ein wo so ein Chip nuetzlich sein koennte, in erster Linie z.B. zur Realisation eines verschluesselten Speichers, SD/Flash was auch immer. Authentifizierung waere so auch moeglich und ausserdem eignet sich AES hervorragend als Zufallszahlenquelle ;) Es gibt da zwar schon was auf dem Markt aber das ist oft sehr teuer und nur an Windows gebunden, so haette man eine viel bessere Loesung.
Das gibt's schon für den AVR: http://point-at-infinity.org/avraes/ Als eigener Chip macht das nicht viel Sinn, vor allem nicht auf AVR-Basis; in der Geschwindigkeit in der das der AVR schafft macht das ein etwas größerer Controller (ARM) locker nebenher. > Ausserdem hab ich im Forum zu AES nur einen Beitrag gefunden. Das sind schon ein paar mehr: http://www.mikrocontroller.net/search?query=aes&forums%5B%5D=1&forums%5B%5D=9&forums%5B%5D=10&forums%5B%5D=2&forums%5B%5D=4&forums%5B%5D=3&forums%5B%5D=6&forums%5B%5D=17&forums%5B%5D=11&forums%5B%5D=8&forums%5B%5D=12&forums%5B%5D=14&forums%5B%5D=7&forums%5B%5D=5&forums%5B%5D=15&forums%5B%5D=13&forums%5B%5D=16&max_age=-
> Das gibt's schon für den AVR Es gibt ALLES schon. Ich hab extra geschrieben das ist hier nicht der Punkt. Es geht um Verstaendnis, ich muss das Zeug wenn es sein muss per Hand rechnen koennen. openPGP auf der shell aufrufen kann sicherlich jeder. Ausserdem macht es wenig Sinn wegen so ner Sache nen fetten ARM zu holen, nur weil der das mal "so nebenbei" kann. Mein Rechner daheim mit seinen Gigahertzen und Terrabytes macht das auch mal "so nebenbei". Oh Leute ich geb's auf mit Euch...
Ein AVR als dedizierter Verschlüsselungs-Chip hat nun mal keinen Sinn, auch wenn du das nicht hören willst. Wenn du nur den Algorithmus zwecks Verständnis implementieren willst, dann mach's doch einfach, warum fragst du hier nach Nebensächlichkeiten wie dem Hardware-Interface?
Nu gut dann werde ich die Sache halt fuer mich entwickeln. Falls doch noch jemand (ernsthaftes) Interesse hat und sich evt. etwas beteiligen will, kann er sich gerne bei mir melden: ICQ 307682079. Ich seh's jedenfalls nicht ein das hier jetzt so runtermachen zu lassen. Die Zeit fuer solche Diskussionen kann ich besser aufwenden. Michael
Andreas hat aber Recht und dich hat in keinerster Weise irgendjemand runter gemacht. Davon abgesehen besteht hier immer Interesse in der CodeLib einen guten Source zu sammeln, also auch deine AES Source ist willkommen. Gruß Hagen
Hier lesen tausende Leute mit, lass dich doch nicht von 2 Leuten irritieren, die deine Idee nicht sinnvoll finden. Nach meinem Geschmack warst du aber auch etwas schnell von oben herab mit deiner Aussage "Leute, ich gebs auf..." Das du nach sowas keinen Beifall erntest, sollte klar sein. Ich find's jedenfalls gut, AES auf dem AVR interessiert mich auch. Hab da zwar konkret derzeit keine Verwendung, lese aber gerne etwas über deine Fortschritte. Vielleicht brauch ich das ja mal irgendwann. Zu diesem Thema: Ich hatte mal überlegt, mir eine kleine Passwort-Box mit AVR zu bauen, wo man alle möglichen Passwörter ablegen kann und mittels Masterpasswort Zugriff hat. Sowas ist viel sicherer, als eine Softwarelösung auf einem PC, wo Trojaner dann doch Tastatur mitloggen können und das ganze nichts bring.
@Winfried: es gibt schon diverse Crypto-Funktionen für den AVR. Neben AES (siehe Link oben) auch XTEA, MD5, SHA1 usw. Such mal im Forum, da findest du einiges. @Michael G.: Asymmetrische Verfahren (RSA, ElGamal, DH, ...) sind noch eine Marktlücke, wäre so was vielleicht ein Alternativprojekt?
@ Michael G. (linuxgeek) ich find das Projekt interessant. Wie auf der "AES on AVR" seite gezeigt, ist man mit 3k Code dabei. dh es ist auf einem Mega8 implementierbar. Wenn man die Funktionalitaet braucht, holt man den 1.10 Euro Chip aus dem Sleep. Als Hardware Interface waere SPI bevorzugt. Es wuerde 3 zusaetzliche Handshake Leitungen brauchen. Eines fuer das Einlesen des Schluessel, eines fuer einen Datenblock, und noch eins fuer Dataready. Was haelt jemanden davon ab, den gelisteten Code selbst zu implementieren ? Tja ... nichts.
OK ich gebe unumwunden zu: Ich hab's mal im Kopf ueberschlagen und es wird wohl nicht besonders schnell sein. Aber um z.B. die Daten auf einer seriellen Verbindung zu verschluesseln wuerde es allemal reichen, fuer Massenspeicher eher weniger. Und wenn's dazu taugt dass ich den Cipher im Detail verstanden habe bin ich im Prinzip schon zufrieden... ;) Und es hat nen weiteren positiven Effekt: Ich hab mit dem SPI-Interface bisher noch nichts gemacht also gleich 2 Fliegen mit einer Klappe geschlagen. Greets, Michael
Winfried wrote: > Hier lesen tausende Leute mit, lass dich doch nicht von 2 Leuten > irritieren, die deine Idee nicht sinnvoll finden. > > Nach meinem Geschmack warst du aber auch etwas schnell von oben herab > mit deiner Aussage "Leute, ich gebs auf..." Das du nach sowas keinen > Beifall erntest, sollte klar sein. Yo ich war ziemlich genervt heute im Buero... man moege es mir verzeihen. > Ich find's jedenfalls gut, AES auf dem AVR interessiert mich auch. Hab > da zwar konkret derzeit keine Verwendung, lese aber gerne etwas über > deine Fortschritte. Vielleicht brauch ich das ja mal irgendwann. Yau > Zu diesem Thema: Ich hatte mal überlegt, mir eine kleine Passwort-Box > mit AVR zu bauen, wo man alle möglichen Passwörter ablegen kann und > mittels Masterpasswort Zugriff hat. Sowas ist viel sicherer, als eine > Softwarelösung auf einem PC, wo Trojaner dann doch Tastatur mitloggen > können und das ganze nichts bring. Das waere z.B. eine gute Anwendung und die Leistung wuerde auf jeden Fall dafuer ausreichend. Und AES ist richtig verwendet ein sehr sicherer Cipher.
Wenn man die Daten unverschlüsselt überträgt kann man sich die Verschlüsselung auch gleich sparen...
@Andreas: >Asymmetrische Verfahren (RSA, ElGamal, DH, ...) sind noch eine >Marktlücke, wäre so was vielleicht ein Alternativprojekt? Ich glaube es gibt da schon was für den AVR, war wohl ECC in GF(2). Gruß Hagen
> Ich glaube es gibt da schon was für den AVR, war wohl ECC in GF(2). http://research.sun.com/projects/crypto/CHES_2004.pdf
> Wenn man die Daten unverschlüsselt überträgt kann man sich die > Verschlüsselung auch gleich sparen... Soll ich in einer Aussage "1 = 1" einen besonderen Sinn erkennen? > Asymmetrische Verfahren (RSA, ElGamal, DH, ...) sind noch eine > Marktlücke, wäre so was vielleicht ein Alternativprojekt? Das is nochmal eine andere Liga. Ausserdem waere das dann sicher zu langsam, das ist ja schon auf nem ausgewachsenem Rechner quaelend langsam. Fuer einzelne Kryptogramme koennte man es aber denke ich mal machen. Mal sehen...
>Das is nochmal eine andere Liga. Ausserdem waere das dann sicher zu >langsam, das ist ja schon auf nem ausgewachsenem Rechner quaelend >langsam. Das stimmt so mal garnicht. Die Erzeugung von Schlüsseln kann man eventuell noch als langsam betrachten, wobei zb. meine Library für den PC im Durchschnitt 50ms benötigt um einen 1024 Bit RSA Schlüssel zu erzeugen oder ca. 10ms um eine komplette Elliptische Kurve in GF(p), 196 Bit groß, zu erzeugen. Das ist defakto sogar sehr schnell für einen PC, wenn man weis was sich da an Berechnungen verbergen und wenn man weis das GF(p) Berechnungen die langsammsten sind und wenn man weis was es heist eine ECC erstmal zu erzeugen, deren Faktorisierung per modulare Polynome usw. Da kommen mal eben schnell weit mehr als 100.000 math. Operationen mit Langzahlen zusammen, und das dann alles zusammen 10ms. Wenn du das PDF von oben durchliest dann bedarf es auf ATMega128 für eine 192 Bit ECC Operation gerade mal 1200ms und das halte ich für noch besser hinzubekommen. Das ist ebenfalls eine akzeptable Zeit und schon ziemlich schnell. Besonders wenn man bedenkt das die die ECC in GF(p) imnplementiert haben und man weis das ECC in GF(2^m) weitaus schneller zu bekommen sind. Die vergleichbare Operation auf einem PC dauert weniger als 1ms. Das wären dann zb. 1000 Schlüsselaustausche pro Sekunde nach DH. Das ist schon eine beachtliche Zahl wenn man bedenkt das alles in reiner Software berechnet wird. Also wenn auf einem PC eine Software langsam ist dann liegt das eher an der schlechten Implementierung. Gruß Hagen
Michael G. wrote: >> Wenn man die Daten unverschlüsselt überträgt kann man sich die >> Verschlüsselung auch gleich sparen... > > Soll ich in einer Aussage "1 = 1" einen besonderen Sinn erkennen? > Nochmal, wenn die Daten unverschlüsselt z.B. über SPI eingelesen und dann verschlüsselt wieder ausgegeben werden, kann man sich das ganze sparen. Rest siehe weiter unten... >> Asymmetrische Verfahren (RSA, ElGamal, DH, ...) sind noch eine >> Marktlücke, wäre so was vielleicht ein Alternativprojekt? > > Das is nochmal eine andere Liga. Ausserdem waere das dann sicher zu > langsam, das ist ja schon auf nem ausgewachsenem Rechner quaelend > langsam. Fuer einzelne Kryptogramme koennte man es aber denke ich mal > machen. Mal sehen... Zusammen mit AES ist das ganze schon brauchbarer z.B. wenn nur die Sessionkeys mit einem asymmetrischen Verfahren ausgetauscht/verschlüsselt werden und der Rest dann mit dem schnelleren AES gemacht wird (hybride Verschlüsselung). Dann hätte man einen (mehr oder weniger) gesicherten Übertragungskanal und den Vorteil, dass die privaten Schlüssel für AES auf dem Controller liegen.
Wenn die privaten Schlüssel für AES auf dem Controller liegen und deren Counterpart auf dem einbruchsicheren Server der Firma, dann benötigt man keine asym. Kryptrographie mehr. Selbst dann nicht wenn man neue Schlüssel aus sichere Weise übertragen möchte, geht dann auch per sym. Verfahren. Wir gehen davon aus das der AVR einbruchsicher ist. In den meisten Fällen trifft dieses Szenario zu, zb. PPP Verbindungen, Funk etc.pp. Man kann also sehr oft mit sym. Kryptographie alleine auskommen. Für weitergehende krypto. Protokolle, zb. Dongles etc.pp., die eben digitale Signaturen erzeugen, überprüfen können, und am PC angeschlossen werden gibt es dagegen schon fertige und sehr preiswerte Möglichkeiten. So wie es Andreas schon sagte, auf einem AVR sehe ich weniger die Notwendigkeit einer solchen Library. Eben weil es preiswerters, billigeres, einfacheres schon gibt. Der Aufwand lohnt also nur aus rein akademischen Gesichtspunkten. Gruß Hagen
> In den meisten Fällen trifft dieses Szenario zu, zb. PPP Verbindungen, Funk > etc.pp. Man kann also sehr oft mit sym. Kryptographie alleine auskommen. So exotisch sind TLS/SSL, IPsec, S/MIME etc. auch nicht mehr (z.B. einige Freemailer die TLS/SSL + POP3/SMTP unterstützen)
Richtig, ich bezog meine Aussage aber auf Hardware mit begrenzten Resourcen, zb. eben AVR, PPP zwischen solchen Controllern, zb. iButton, Bluetooth, WLAN usw. und nicht auf PCs. Gruß Hagen
>Nochmal, wenn die Daten unverschlüsselt z.B. über SPI eingelesen und >dann verschlüsselt wieder ausgegeben werden, kann man sich das ganze >sparen. Tatsaechlich ? Das kommt auf die Beziehung zwischen lokalem Geraet und dem Benutzer an. Die koennen ja "befreundet" sein und die Uebertragungsstrecke des verschluesselten Signales kann "feindlich" sein. Dann kann auch der momentan geladene Schluessel fuer den "interessierten" Benutzer abgreifbar sein. Be einem solchen Setup sollte man dann nicht statischen Schluesseln arbeiten, sonder immer einen neuen laden.
Hallo erstma, und danke fuer die Beteiligung: Hagen: Du redest total am Thema vorbei, von elliptischen Kurven ist hier keine Rede. Und wenn ein PC 100.000 Operationen in wenigen Millisekunden ausfuehren kann man das zwar schnell sein, aber ein Mikrocontroller wuerde um viele Faktoren langsamer sein. Und mit langsam meine ich hier den Durchsatz an Kryptogrammen. Mit anderen Worten: asymmetrische Chiffres waeren nochmal wesentlich langsamer als z.B. ein AES und da wuerde ja schon bemaengelt dass es nicht "besonders" schnell ist was sicher wahr ist. Aber ich denke es kann noch Sinn machen. Arc: > Nochmal, wenn die Daten unverschlüsselt z.B. über SPI eingelesen und > dann verschlüsselt wieder ausgegeben werden, kann man sich das ganze > sparen. Wenn Du bei solchen Systemen an der richtigen Stelle angreifst ist Verschluesselung immer uneffektiv. Wenn ich Dir Deine Daten vor oder nach dem Verschluesseln auslesen kann, haste nicht viel gewonnen. Das ist aber auch nicht das Ziel von Kryptographie. Wenn Du Daten ueber unsichere Leitungen uebertraegst, wirst Du das verschluesselt tun wollen. Du kannst nicht davon ausegehen dass ein Angreifer ohne weiteres die Signale auf Deiner Platine abgreifen kann, das wirst Du anders schuetzen muessen. 2961 hat es ebenfalls richtig erkannt. > Zusammen mit AES ist das ganze schon brauchbarer z.B. wenn nur die > Sessionkeys mit einem asymmetrischen Verfahren > ausgetauscht/verschlüsselt werden und der Rest dann mit dem schnelleren > AES gemacht wird (hybride Verschlüsselung). Dann hätte man einen (mehr > oder weniger) gesicherten Übertragungskanal und den Vorteil, dass die > privaten Schlüssel für AES auf dem Controller liegen. Das ist wohl wahr, brauchst nur noch so ein Schluesselaustauschprotokoll und die Sache is gebongt. Allerdings ist das schon wieder ne ganze Stufe weiter und wirklich alles andere als trivial, ein Problem duerfte z.B. alleine sein, auf mein Mikrocontroller mit grossen Zahlen zu rechnen und es wird zwangslaeufig langsam sein. Der private Schluessel koennte aber zwangslaeufig sicher verwahrt im Controller verbleiben. Hagen: > Wenn die privaten Schlüssel für AES auf dem Controller liegen und deren > Counterpart auf dem einbruchsicheren Server Du meinst RSA, nehm ich mal an.
>Hagen: >>Wenn die privaten Schlüssel für AES auf dem Controller liegen und deren >>Counterpart auf dem einbruchsicheren Server der Firma, dann benötigt man >>keine asym. Kryptrographie mehr. >Du meinst RSA, nehm ich mal an. nein meine ich nicht, zitiere bitte inhaltlich korrekt. RSA ist asymmetrisch und AES zb. ist symmetrisch. Wenn beide Endstellen in einer Kommunikation einbruchsicher sind, zb. eben ein AVR und ein Server, dann reichen symmetrische Verfahren aus. Du sagtest: >>Das is nochmal eine andere Liga (bezog sich aus asymmeteische Verfahren) >>Ausserdem waere das dann sicher zulangsam, das ist ja schon auf nem >>ausgewachsenem Rechner quaelend langsam. >Das stimmt so mal garnicht. Antwortete ich. Das bezog sich auf deine Behauptung das asymmetrische Verfahren heutzutage quälend langsam auf einem Rechner = PC sein sollen. Als Beleg meiner Aussage legte ich dir praktische Erfahrungen mit meiner eigenen realen und getesteten Softwareumsetzung solcher Verfahren vor. Ich dachte du möchtest zuhören und reale Fakten und Erfahrungen Anderer hören. Sogesehen meine ich das ich eben nicht am Thema vorbeirede, denn dieses Thema umfasst auch dein falsches Wissen, bzw. Unwissen. Das ist jetzt kein Angriff auf deine Person als solches sondern nur ein Versuch einige Punkte deines Wissen zu erweitern. Gruß Hagen
Nochmal zu Arc's Aussage: Du verstehst ihn da quasi nur eindimensional. Arc denkt einfach ein Stückchen weiter als du. Er geht von deiner eigenen Prämisse aus, eben einen AVR als Kryptrochip zu programmieren bei dem du von uns eingangs wissen wollstest welches Datenprotokoll/Schnittstelle am geeignesten wäre. Kryptographsich gesehen hat Arc mit seinem Einwand absolut Recht, denn was nützt ein Krypto-AVR der auf der Platine unverschlüsselt mit der Peripherie kommuniziert wenn die Platine selber im Bereich des Angreifers ist. Die Annahme das diese Platine und damit die Inter-CPU-Kommunikation auf der Platine einbruchsicher ist ist falsch. Das ist das Hauptargument auf das sich Arc indirekt bezog. Es wird dann ein Schuh draus wenn deine AES-Routinen direkt in den gleichen AVR abgelegt werden der immer nur verschlüsselt mit der Außenwelt kommuniziert und gleichermaßen auch die empfangenen/gesendeten Daten verwertet. Würde dieser AVR aber nur als Kryto-Durchlaufposten agieren, also unverschlüsselt die Daten an andere Prozessoren auf der Platine weiterleiten reduziert sich die ach so schöne Sicherheit und damit auch der getätigte Aufwand in der Entwicklung auf defakto NULL. Da deine Frage sich Eingangs auf eine passende Schnittstelle/Protokoll für einen solchen Krypto-AVR bezog ist der logische Gedanke den Arc weiterverfolgte eigentlich offensichtlich. Die Fragestellung der Schnittstelle/Protokoll ist also sinnlos, da es im grunde immer darauf hinausläuft das ein Anwender deiner AES-Engine den Source drekt in sein Projekt einbaut und dieses dann eben auf einen einbruchsicheren AVR brennt. Dieser AVR wird dann wenn er extern kommunizieren möchte alle seine Daten verschlüsselt empfangen und senden und ausschließlich nur intern mit den entschlüsselten Daten arbeiten. Es ist das A&O es so zu machen, niemals dürfen unverschlüsselte Daten die geschützt sein sollen an die Außenwelt gelangen. Dann und nur dann ist es kryptographisch sicher. Fazit: deine Fragestellung ist ein Widerspruch in sich. Denk mal drüber nach, denn das beantowrtet auch dein Problem wie du die Schlüssel auf sichere Weise in den AVR bekommst. Mal anderst ausgedrückt: angenommen wir hätten deinen Krypto-AVR dann müssten wir bei der Kommunikation auf der Platine mit einem anderen AVR diese Kommunikation ebenfalls absichern. Somit bauen wir die gleiche Funktionalität deinen Krypto-AVR ind den zweiten AVR ein. Aus diesem wird dann ein Krypto-AVR. Nun wollte dieser selber auch daten von einem dritten AVR auf der Platine bekommen, zb. Schlüssel damit der Krypto-AVR arbeiten kann. Ergo: auch der 3. AVR wird zu einem Krypto-AVR damit es sicher wird. Diese Spirale kannst du in die Unendlichkeit fortsetzen und das beweist das dein grundsätzliches Konzept irgendwie sinnfällig sein muß. Also, am besten ist es eine gute AES Library als OpenSource abzuliefern die dann vom Endanwender direkt in den AVR eingebaut wird der auch die Daten produziert oder weiterverarbeitet. Die Frage nach dem richtigen Protokoll oder Schnittstelle stellt sich dann garnicht mehr, da dies nämlich individuell vom Projekt des Endanwenders deiner Library abhängt. Gruß Hagen
>> Zusammen mit AES ist das ganze schon brauchbarer z.B. wenn nur die >> Sessionkeys mit einem asymmetrischen Verfahren >> ausgetauscht/verschlüsselt werden und der Rest dann mit dem schnelleren >> AES gemacht wird (hybride Verschlüsselung). Dann hätte man einen (mehr >> oder weniger) gesicherten Übertragungskanal und den Vorteil, dass die >> privaten Schlüssel für AES auf dem Controller liegen. >Das ist wohl wahr, brauchst nur noch so ein Schluesselaustauschprotokoll >und die Sache is gebongt. Allerdings ist das schon wieder ne ganze Stufe >weiter und wirklich alles andere als trivial, ein Problem duerfte z.B. >alleine sein, auf mein Mikrocontroller mit grossen Zahlen zu rechnen und >es wird zwangslaeufig langsam sein. Der private Schluessel koennte aber >zwangslaeufig sicher verwahrt im Controller verbleiben. Siehst du, auch hier lösen sich deine Probleme in Luft auf wenn du davon ausgehen würdest das dein AES im gleichen AVR drinnen ist der auch die Daten verarbeitet. Ein Schlüsselaustausch ist dann mit AES alleine sicher zu bekommen. Dazu gibts schon einen vorprogramierten Schlüssel im AVR. Dieser dient zu Verschlüsselung eines Austausches einen neuen zufällig gewählten Schlüssels. Wenn nun beide Seiten der Kommunikation einbruchsicher sind, zb. zwei AVRs oder zwei Server oder 1 AVR und 1 Server, dann ist das sicher. Auch ohne aufwendige asymmetrische Kryptrographie, zb. RSA oder ECC. An die unverschlüsselten Daten, wie eben der neue Schlüssel, kommt man dann nicht ran, weil sie immer nur innerhalb des geschützten AVRs unverschlüsselt zu Verfügung stehen. Am besten lese dich mal über den iButton von Dallas Maxim und deren Protokolle an. Gruß Hagen
> Ich dachte du möchtest zuhören und reale Fakten und Erfahrungen Anderer > hören. Sogesehen meine ich das ich eben nicht am Thema vorbeirede, denn > dieses Thema umfasst auch dein falsches Wissen, bzw. Unwissen. Hagen, schon recht. Tu mir nen Gefallen und uebe Deinen Profilierungdrang in einem anderen Thread aus. Oeffne z.B. einen neuen.
>Hagen, schon recht. Tu mir nen Gefallen und uebe Deinen >Profilierungdrang in einem anderen Thread aus. Oeffne z.B. einen neuen. Das ist kein Problem für mich. Gruß Hagen
Der Thread bis hierher war interessant. Es gibt immer verschiedene Ansaetze, je nach Kontext. Der Kontext kann nicht immer vorausgesetzt werden. Wenn der Kontext anders ist, so aendern sich auch die Schlussfolgerungen. Nehmen wir einen Kreditkartenleser, der soll eine gesicherte Verbindung zur Kartenfirma machen. Der Vorgang ist langsam genug, die Zeit reicht um zur Verbindungsaufnahme ein asymmetrisches Verschluesselungsprotokol zu fahren und fuer die Daten ein Symmetrisches. Dafuer ist ein AVR genuegend. Die Information der Karte sind auf dem Magnetstreifen, dazu kommen noch die 4 bis 6 Zahlen des PIN. Fuer diese Anwendung kann man einen AVR als Kryptochip nehmen und die chips mit SPI verbinden. Es gibt da nichts Geheimes. Ja, ein dummer Techniker koennte das SPI anzapfen und so die Magnetspurinformation und den Pin bekommen. Diese beiden informationen sind aber auf der Hardware sonst noch vorhanden. zB am Magnetspurleser und am Keyboard. Da ist es technisch viel einfacher die Karte durch einen Leser zu ziehen und den PIN visuell abzuschauen. Nein ? Hab ich was uebersehen ?
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.