Forum: Mikrocontroller und Digitale Elektronik µC mit asymmetrischer Verschlüsselung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von David91 (Gast)


Lesenswert?

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ß

von Daniel H. (Firma: keine) (commander)


Lesenswert?

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?

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

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

von Ukat (Gast)


Lesenswert?

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.

von Daniel H. (Firma: keine) (commander)


Lesenswert?

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.

von Mike (Gast)


Lesenswert?

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.

von Washington I. (washington_i)


Lesenswert?

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.

von Daniel H. (Firma: keine) (commander)


Lesenswert?

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.

von Daniel H. (Firma: keine) (commander)


Lesenswert?

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
Bitte 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
Noch kein Account? Hier anmelden.