mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AES fuer Mikrocontroller


Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&fo...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: 2961 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man die Daten unverschlüsselt überträgt kann man sich die 
Verschlüsselung auch gleich sparen...

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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)

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 2961 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: 2961 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.