Hallo, ich brauche ein µC das ECDSA oder RSA unterstützt. Oder eine andere asymmetrische Verschlüsselung. Ich habe zwar schon gesucht aber ehrlich gesagt nicht sehr viel gefunden und bin mir etwas unsicher. Was könnt ihr da empfehlen? Gruß
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.
Daniel H. schrieb: > 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. Warum die Geheimniskrämerei? Wirkt nicht sehr vertrauenerweckend. Ich bin eher ein Freund der Denkweise das Transparenz Sicherheit und Vertrauen erhöht. Danke jedenfalls für die Aufzählung. Die von Maxim fand ich schon.
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.
Wozu brauchst du denn sowas? Üblicherweise verwendet man asymmetrische Verschlüsselung (wegen des Rechenaufwands) nur zum Schlüsselaustausch. Dafür sollte auch die CPU ausreichen. Der Rest der Kommunikation erfolgt dann mit AES oder 3DES. Das sollte die Auswahl an Controllern deutlich vergrößern... Daniel H. schrieb: > 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. Könnte natürlich auch sein das die Hersteller sich bei sicherheitsrelevanten Sachen sich nicht so einfach in die Karten schauen lassen wollen. Das erschwert es dann etwas Angriffspunkte zum Aufhebeln der Sicherheit zu finden. Einen Angreifer mit entsprechenden Resourcen wird das natürlich nicht aufhalten.
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.
:
Bearbeitet durch User
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.