µC mit asymmetrischer Verschlüsselung

David91 schrieb:
> Ich habe zwar schon gesucht aber ehrlich gesagt nicht sehr viel gefunden
> und bin mir etwas unsicher.

Das liegt oftmals daran, dass die Hersteller solche Controller nicht 
ohne Weiteres frei verkaufen und auch die Doku oftmals nur unter NDA zu 
kriegen ist.

Spontan fallen mir mit ECDSA/RSA als Controller MAXQ1103, MAXQ1850 bzw. 
MAXQ1851 von Maxim ein. Dann von NXP noch die SmartMX2-Serie sowie von 
Infineon die SLE77-/SLE88-Serie (die beiden letzten sind aber eher 
Smartcard-COntroller).

Gegenfrage: was hast du mit dem µC vor, was soll er sonst noch können? 
Denn ich denke, der Kryptobeschleuniger soll ja nur einen Teil 
ausmachen, oder?

Ein STM32F417, STM32F42x, STM32F43x hätte ein TDES, ein AES256 und HASH 
HW-Seitig implementiert.
Falls das in frage käme.

Ukat schrieb:
> Warum die Geheimniskrämerei? Wirkt nicht sehr vertrauenerweckend. Ich
> bin eher ein Freund der Denkweise das Transparenz Sicherheit und
> Vertrauen erhöht.

Das sehe ich ähnlich. Allerdings möchten die Hersteller ihre Hardware ja 
auch gerne sicherehitszertifizieren lassen. Meine Vermutung ist, dass 
eine Anforderung dafür ist, dass sicherheitsrelevante Informationen eben 
nur einem eingeschränkten Personenkreis zugänglich gemacht werden. Ich 
würde davon ausgehen, dass jeder der möchte auch die entsprechenden 
Specs kriegen kann, aber eben erst nach Registrierung und 
Personalisierung der entsprechenden Dokumente.

Hallo,

darf es softwareseitig sein?

http://www.das-labor.org/wiki/AVR-Crypto-Lib
Hier ist eine Sammlung von Cryptoalgorithmen, für 8Bit gemacht.
Bei asymmetrischer Verschlüsselung wird es schnell rechenintensiv. 
Elliptische Kurven sind - zumindest für mich - recht schwierig, Diffie 
Hellmann Schlüsselaustausch und danach symmetrisch mit einem 
abgewandelten RC4 ist dagegen wohl auch mit nem popeligen Atmega machbar 
(dauert etwas zum ausrechnen). Viel Spass beim rechnen lassen.

Soll es recht einfach sein? So dass man es gegebenenfalls auch mit einem 
besseren Taschenrechner und viel Zeit machen kann? Und andererseits so 
ausbaubar, dass es nicht geknackt werden kann, bis das 
Faktorisierungsproblem gelöst ist?

Die Lösung: Diffie Hellmann Schlüsseltausch
http://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch

Beide Seiten einigen sich auf eine große ungerade Zahl, im Idealfall: 
Primzahl, diese Zahl ist offen.
Jede Seite sucht sich eine große Primzahl. Diese Primzahl ist der 
jeweilige Secret Key, mit dem zusammen mit der obigen Zahl ein Public 
Key erzeugt wird.
Die beiden Seiten tauschen also die Public Keys aus, mit dem jeweiligen 
Secret Key können beide Seiten ein gemeinsames Secret erzeugen.

Mit dem gemeinsamen Secret kann man dann einen symmetrischen 
Streamcipher laufen lassen, und alle Nase lang ein neues Secret 
austauschen.

Mit am einfachsten finde ich den hier: http://ciphersaber.gurus.org/ 
auch wenn das nicht mehr ganz "state of the art" ist.

Würde mich freuen, wenn es mehr "anfängerfreundliche" offene 
Verschlüsselungsalgorithmen gäbe.

Mike schrieb:
> Üblicherweise verwendet man asymmetrische
> Verschlüsselung (wegen des Rechenaufwands) nur zum Schlüsselaustausch.
> Dafür sollte auch die CPU ausreichen.

Das würde ich so nicht sagen.

> http://en.pudn.com/downloads288/sourcecode/embedded/detail1299669_en.html

Hier haben sie die Performance von RSA und ECC u.a. auf einem 
Atmega128@8MHz verglichen. RSA-Entschlüsselung bzw. -Signaturerzeugung 
dauert mit einem 2048 Bit-Schlüssel auf dem Atmega knapp 84 Sekunden. 
Selbst wenn damit nur ein symmetrischer Schlüssel ausgetauscht werden 
soll ist das in den meisten Anwendungen nicht mehr akzeptabel. Und 
sofern es sicher sein soll würde ich heutzutage auch keine kleineren 
öffentlichen RSA-Schlüssel als 2048 Bit mehr einsetzen.

Auf einem etwas potenteren, höher getakteren µC (ARM, Atxmega usw.) 
könnte das aber schon hinhauen.

Washington I. schrieb:
> Die Lösung: Diffie Hellmann Schlüsseltausch

Das Problem: Diffie-Hellmann standalone ist nicht sicher gegen 
Man-in-the-middle-Angriffe. Wollen zwei Parteien A und B miteinander 
kommunizieren kann sich Angreifer C somit zwischen A und B hängen und 
jeweils (ohne dass diese es merken) einen eigenen 
Diffie-Hellmann-Schlüsselaustauschen mit beiden durchführen und die 
Nachrichten anschließend relayen.

Edit sagt: RC4 würde ich übrigens nicht mehr einsetzen, seit dem 
NSA-Skandal kann man davon ausgehen, dass es gebrochen ist. Ich würde 
hier auf AES mit 128 oder besser noch 256 Bit-Schlüsseln setzen.

Solange der TO aber nicht sagt, was er vor hat ist das hier irgendwie 
Hellseherei und Empfehlungen zu geben etwas schwierig.