Krypto auf Mikrocontroller

Hallo Bernd,

wenn du WPA/WPA2 in Zusammenhang mit einem RADIUS-Server verwendest, 
kannst du dich auch mit Zertifikaten authentifizieren. Das halte ich für 
deutlich sicherer und vorallem erprobter, als hier irgendeine eigene 
Lösung zu basteln (mir RSA ist das noch lange nicht getan ...).

Soll denn auch der Netzwerkverkehr über deinen Atmel-Prozessor gesendet 
werden? Falls ja, brauchst du schon einen ziemlich leistungsfähigen 
Prozessor ...

Gruß
Stephan

Er hat ja nur von Atmel geschrieben. Von AVR war da ja nicht die Rede. 
Ein AT91SAM9 kostet ja auch nicht die Welt.

fchk

Hab ich denn etwas von AVR geschrieben? ;)

Ist zwar nicht ATMEL, aber die STM32F2xx-Käfer könnten vermutlich auch 
gut passen. Die haben sogar 'nen Random Geni drin. :-)

Hallo Bernd,

was benötigst du denn, was das EAP nicht abdeckt?
http://de.wikipedia.org/wiki/Extensible_Authentication_Protocol

Gruß
Stephan

Hallo,

was willst du genau machen und was meinst du damit dass du die 
Sicherheit besser einstellen willst als es mit WEP/WPA möglich ist? Und 
was genau hast du mit RSA/DSA vor? Üblicherweise werden die nur zum 
Austausch von Schlüsseln für symmetrische Kryptoverfahren verwendet, 
einfach weil die Ver- und Entschlüsselung sehr viel länger dauert. Wir 
sprechen hier von Zeiten die teilweise im Bereich von Sekunden (pro 
Ver-/Entschlüsselung) liegen, so dass man eine deutliche Latenz hätte.

Ich will nicht sagen, dass es unmöglich ist, aber die kleineren µC 
stoßen hier ganz sicher sehr schnell an ihre Grenzen. Das Wichtigste 
wäre allerdings, wenn der Sicherheitsanspruch so groß ist, dass nur 
getestete und geprüfte Implementierungen von Kryptoalgorithmen verwendet 
werden, da man ansonsten mit hoher Wahrscheinlichkeit das Ganze 
unsicherer macht als wenn man Standard-Wifi-Verschlüsselung nutzen 
würde. So ist z.B. RSA in der Form, wie es oft vorgestellt/erklärt wird 
anfällig gegen diverse Angriffe.

Viele Grüße,
Daniel

> also ich will sicherstellen, dass das Modul auch wirklich das
> entsprechende Modul ist. Das heißt digitale Signierung. Dann will ich
> Daten austauschen über eine Verschlüsselte Verbindung.

Ja das will jeder so machen. Dafür nimmt man aber 2 Verfahren.

Erstmal wird mittels Zerifikaten und deren asymetrischen Schlüsseln
a.) Der gegenüber Authentifizert und
b.) Parameter für den Schlüsselaustausch verschlüsselt und ausgetauscht 
(z.B. Diffie-Hellman)
Diese beiden Dinge geschehen eigentlich gleichzeitig da die DH Parameter 
eigentlich nicht verschlüsselt werden müssten. Durch die Verschlüsselung 
per öffentlichem Schlüssel des Gegenüber wird sichergestellt dass dieser 
im Besitz des entsprechenden privaten Schlüssels ist und somit weiß man 
dass man mit dem erwarteten Partner redet.

Dann wird mit dem ausgehandelten symetrischen Schlüssel die restliche 
Kommunikation gesichert.

Falls du es etwas einfacher haben willst, kannst du auch direkt von 
einer Partei einen symetrischen Schlüssel generieren lassen und diesen 
dann per assymetrischer Verschlüsselung  (aus einem Zertifikat) sichern 
und der anderen Partei senden. Dann haben auch beide den symetrischen 
Schlüssel. Das bietet dann allerdings keine "Perfect Forward Secrecy", 
aber die Frage ist ob du das brauchst.

gruß cyblord

Authentifikation/Zertifikation ist nicht abhängig von asymmetrischen 
Verfahren wie RSA/DSA usw. Du kannst auch eine 
Authentfikation/Zertifikation mit symmetrischen Verfahren durchführen. 
Dafür gibt es viele Beispiele, und das sind alle bei denen du auf Sender 
und Empfängerseite ein Passwort eingeben musst. Ist dieser Prozess 
sicher dann ist diese Art der Authentifzierung genauso sicher wie mit 
asymmetrischen Verfahren.

Ganz im Gegenteil ist es sogar so das erst die asymmetrischen Verfahren 
ein neues Problem genannt "Man in the Middle Attack" verursachen.

RSA/DSA und Konsorten benutzt man weil ein potentieller Empfänger einer 
Nachricht im Vorhinein sicherstellen muß das er verschlüsselte 
Nachrichten an ihn adressiert empfangen möchte, ohne dabei wissen zu 
können von wem er in Zukunft Nachrichten empfangen wird.

Gleiches gilt für Zertifikate im umgedrehten Sinne. Hier möchte eine 
Person Daten signieren ohne im vorhinein wissen zu können wer in Zukunft 
diese Daten auf Echtheit überprüfen will.

Einziger kryptographischer Unterschied zwischen asymmetrischen und 
symmetrischen Authentifizierungen/Signierungen ist als die Frage ob man 
bei der Authentifikation/Signierung das Paswort kennen muß oder nicht. 
In jedem Fall benötigt der Empfänger/Signer ein Passwort egakl ob 
symmetrisches/Asymmtrisches Verfahren. Nur bei der 
Authentifikation/Verschlüsselung von Daten benötigt man bei 
asymmetrischen Verfahren nicht das Passwort, was bei symmtrischen 
Verfahren aber der Fall ist.

Ergo: WLAN, Bluetooth basieren auf symmetrischen Authentifizierungen und 
sind nicht so "unsicher" weil diese Art der Kryptographie ansich 
unsicher oder nicht machbar wäre. Sie sind unsicher weil bei der 
Entwicklung "geschlampt" wurde-musste ;)

Technologisch gibt es aber enorme Unterschiede, asymmetische Verfahren 
sind:
- viel komplizierter und komplexer
- anfälliger bei Fehlern in der Implementierung der Software und 
Protokolle
- viel langsammer
- das nötige Wissen der Nutzer um damit korrekt umgehen zu können ist 
weitaus größer

symmetrische Verfahren sind:
- anwendungssicherer
- einfacher
- schneller

Deshalb gibt es auch kein Softwaresystem das auf reinen asymmtrischen 
Verfahren basiert, man benutzt dann immer Hybride bei denen die 
Hauptarbeit von symmtrischen Verfahren erledigt wird.

Gruß Hagen

gaast schrieb:

> Hagen Re schrieb:
>> Ganz im Gegenteil ist es sogar so das erst die asymmetrischen Verfahren
>> ein neues Problem genannt "Man in the Middle Attack" verursachen.
>
> Halte ich für ein Gerücht.

Stimme dir zu. Warum sollte das so sein? Erst asymmetrische 
Verschlüsselung kann einen Man-in-the-middle Angriff verhindern. Für 
eine symmetrische Verschlüssung muss man ja erstmal den Schlüssel 
austauschen oder man braucht einen festen PSK in beiden Devices was auch 
unsicher ist.

gruß cyblord

Einen AVR ? Ist zwar gut fuer Vieles, aber fuer Krypto Anwendungen zwei 
Nummern zu klein. Unter AVR32 machts keinen Sinn. Allenfalls ein UC3 
oder AP7000.