hallo, ich würde gern einen uC in einen Klinkenstecker einbauen und es gibt ja auch einige im SO-8 Gehäuse. Blöderweise kann ich keinen von denen programmieren, es fehlt an allem, Compiler, Programmieradapter und Erfahrung mit dem uC. Da dachte ich mir, evt. hat hier jemand Lust das für mich zu programmieren? Der genaue Typ ist mir egal, der ATtiny45 ist nur ein Beispiel, es darf auch einer von Freescale, TI oder notfalls ein PIC sein. Ein paar Anforderungen gibt es natürlich: * funktionierender interner Reset (die ATtiny4/5/9/10 gehen nicht) * Betrieb mit sehr schlechten 3.3V (deswegen der gute Reset) * interner Takt, stabil genug für 9600 Baud (es gibt keine externe Referenz) * Bastler-lötbares Gehäuse * 1 Ausgangs-Pin mit UART/USI/OutputCompare oder so * ca. 10 Stück leicht in Deutschland beschaffbar * ordentliches Datenblatt frei verfügbar Was schon klar ist: * das sollen Schlüssel werden, als Ersatz für ein Zylinderschloss * Gehäuse: 6.3mm Klinkenstecker, die Neutrik haben 8mm Innendurchmesser * das Programm und/oder die Reset-Logik wartet, bis die 3.3V stabil sind * einmal pro Sekunde werden 12..16 Byte mit 9600-8N1 gesendet * diese Bytes sind fest, aber bei jedem Chip unterschiedlich * nett, aber nicht wichtig, wäre eine Auswahl per Lötbrücke. Dann könnten alle 8 oder 16 Chips gleich programmiert werden. Danke für's Lesen!
Angehängte Dateien:
-
erster_versuch.png
4,4 KB
Also unter "Programmierservice" dachte ich jetzt du suchst jemanden der
dir eine fertige HEX Datei auf einen Controller schreibt.
Aber du suchst ja eine komplette Embedded SW-Entwicklung.
> das sollen Schlüssel werden, als Ersatz für ein Zylinderschloss
Dann sollte das ganze Kryptografisch gesichert sein. Und keine festen
"Schlüssel" einfach raussenden.
Weißt du was du da tust?
:
Bearbeitet durch User
cyblord ---- schrieb: > Dann sollte das ganze Kryptografisch gesichert sein. Und keine festen > "Schlüssel" einfach raussenden. Eigentlich nicht, weil genau das macht ein herkömmlicher mechanischer Schlüssel auch, er gibt seinen Code ohne Gegenwehr her. Ja sogar das Zylinderschloss selbst gibt den Code her, das würde der Dekodercontroller nicht machen. Klar, elektronisch muss man jetzt nicht die mechanische Schwäche nachahmen...
:
Bearbeitet durch User
Roland ... schrieb: > cyblord ---- schrieb: >> Dann sollte das ganze Kryptografisch gesichert sein. Und keine festen >> "Schlüssel" einfach raussenden. > > Eigentlich nicht, weil genau das macht ein herkömmlicher mechanischer > Schlüssel auch, er gibt seinen Code ohne Gegenwehr her. Ja sogar das > Zylinderschloss selbst gibt den Code her, das würde der > Dekodercontroller nicht machen. > > Klar, elektronisch muss man jetzt nicht die mechanische Schwäche > nachahmen... Und elektronisch kann ich den Schlüssel viel schneller und einfacher nachmachen. In Sekundenbruchteilen. z.B. über ein "Fake-Schloss" welches dann den Schlüssel liest und kopiert. So wie man EC-Karten am Geldautomaten kopieren kann. Darum wird (langsam aber sicher) dort auf Chip umgestellt. Das man eben nicht einfach mal so den ganzen Zauber kopiert. Hier hat man das gleiche Problem. Aber auch gleich die Lösung: Einfach ne bessere SW machen. Per Challenge/Resonse ist am einfachsten. Das kann man dann so weit treiben wie man möchte.
...naja, ältere Zutrittskontrollsysteme senden auch immer die gleiche Karten-ID, nur da ist es noch etwas schwerer an die Karten-ID heranzukommen wenn es drahtlos passiert. Die Frage ist, ob jmd. der den Steckerschlüssel findet etwas damit anfangen kann. Nehmen wir mal an er wäre noch mit einer Vergussmasse gefüllt, so dass man ihn mal nicht schnell auseinandernehmen kann. 99,9% der Bevölkerung wird damit nichts anfangen können, im Gegensatz zu einem normalen Schlüssel (der sich ja auch nachmachen lässt), wo man gleich weiß wozu er gut ist. Außerdem könnte man den Steckerschlüssel relativ einfach & schnell in der Schlossoftware sperren, so dass er nicht mehr akzeptiert wird. EDIT: In einer Sache hat cyblord natürlich recht, jemand der weiß wie Dein Schloss funktioniert, kann den Schlüssel sehr einfach kopieren, eben in Sekundenbruchteilen wenn er sich darauf vorbereitet hat. Grüße Markus
:
Bearbeitet durch User
Markus M. schrieb: > Die Frage ist, ob jmd. der den Steckerschlüssel findet etwas damit > anfangen kann. Nehmen wir mal an er wäre noch mit einer Vergussmasse > gefüllt, so dass man ihn mal nicht schnell auseinandernehmen kann.+ Muss man doch nicht, der sendet doch alles was man braucht, direkt über die Klinkenkontakte raus. > 99,9% der Bevölkerung wird damit nichts anfangen können, im Gegensatz zu > einem normalen Schlüssel (der sich ja auch nachmachen lässt), wo man > gleich weiß wozu er gut ist. Security by Obscurity nennt man diesen Ansatz. Natürlich ist das properitäres System und das versucht erstmal niemand zu knacken weil es niemand kennt. Aber ich würde nie nie nie mit so einer Vorbedingung ein Sicherheitssystem designen. Das ist einfach ein Prinzip. Und es ist realtiv einfach, das ganze zumindest im Ansatz sicher zu machen.
cyblord ---- schrieb: > Per Challenge/Resonse ist am einfachsten. Das kann > man dann so weit treiben wie man möchte. Oder ein Rollingcode, dann kann zumindest die UART mit dem Klinkenstecker genutzt werden. Ansonsten brauchts was Richtung 1-Wire-Bus.
Folgender Ansatz: Jeder Schlüssel hat eine ID und eine Schlüsselnummer S die zum Zugang berechtigt. Das Geheimniss ist S. Der Schlüssel darf dieses niemals einfach so raussenden. Aber das Schloss muss überprüfen können, ob der Schlüssel das Gehmeiniss kennt. Klar. (Zero-Knowledge). Das geht relativ einfach: Das Schloss kennt natürlich alle IDs und Schlüsselnummern dazu. 1.) Wenn nun der Schlüssel eingesteckt wird, schickt das Schloss eine Zufallszahl R an den Schlüssel. 2.) Der schickt seine ID und H(R+S) an das Schloss. H ist eine krypt. Hashfunktion. z.B. MD5 oder SHA1. 3.)Das Schloss kann jetzt einfach überprüfen ob S stimmt, in dem es selbst H(R+S) bildet. Stimmt es überein, ist der Schlüssel ok. Aber niemand kommt an S ran und niemand kann den Schlüssel so einfach kopieren. Das ganze kann man immer sicherer machen, aber so ist es ein Anfang. Man kann auch kompl. rausnehmen. Will man keine echte Hashfunktion im Controller implementieren, dann verwurstet man stattdessen halt irgendwie. Ist dann zwar krypt. nicht mehr sicher, aber besser als ganz ohne. @Roland: Das ganze geht auch über UART halbdupelx über eine Signalleitung.
:
Bearbeitet durch User
Spar Dir den Attiny und nimm 1-Wire Chips von Maxim. Ein Vorschlag wäre der DS28E05, ein 112 Byte EEPROM. http://www.maximintegrated.com/datasheet/index.mvp/id/7979 Maxim hat auch kryptografisch gesicherte Bausteine mit Hardware SHA1 und SHA1 Authentikatorchips. Damit werden zB Akkupacks ausgestattet, um sicherzugehen, dass es Originale und keine Nachbauten sind. Für diese Teile verlangt Maxim allerdings ein NDA, und ich weiß nicht, ob man diese Teile so einfach in kleinen Stückzahlen kaufen kann. Der DS28E05 ist jedoch mindestens so sicher wie Deine Idee, aber einfacher zu fertigen (ein 3-Pinner und gut ist). Es gibt die Teile auch als iButtons in Knopfzellen-ähnlichen Stahlgehäusen. So etwas wäre für Dich auch nett, aber das braucht auch ein NDA: http://www.maximintegrated.com/datasheet/index.mvp/id/3557 fchk
Hi, Stimmt... man kann den 1-wire bus ja wirklich relativ einfach realisieren: Das Schloss wartet erstmal bis es eine "Magicnumber" auf der seriellen Datenleitung empfängt. Danach wechselt es auf Senden und das Verfahren wie von cyblord beschrieben kann stattfinden. Praktisch kann man ja Sende/Empfangspins über einen Widerstand (zum Schutz) verbinden, wenn man den normalen UART verwenden möchte. Wenn aus irgendwelchen Gründen der Handshake bzw. die Challenge/Response fehl schlägt, geht das Schloß erstmal wieder auf Empfang und der Schlüssel versucht nach einem Timeout den Vorgang erneut. Grüße Markus
Markus M. schrieb: > Praktisch kann man ja Sende/Empfangspins über einen Widerstand (zum > Schutz) verbinden, wenn man den normalen UART verwenden möchte. Oder man nimmt einen SW-UART und programmiert den direkt nur auf einem Pin. Das ist erprobt. z.b. für diverse Sensoren im Modellbaubereich (HoTT, Jeti, M-Link). Will man tatsächlich eine HW-UART verwenden, so sollte man eine Diode in die TX Leitung machen (in Sperrichtung zum TX-Pin) und dahinter einen Pull-Up. Und dann mit RX verbinden. So kann die TX-Leitung nur auf GND ziehen oder loslassen. Ist auch erprobt um diverse USB-UART Wandler genau so halbduplex auf einer Leitung zu betreiben. Auch muss man den Schlüssel nicht sofort mit S programmieren. Man kann das ganz entspannt ebenfalls über den UART später noch machen. Das einrpogrammieren einer ID und S ist nicht Sicherheitsrelevant und man könnte dies ohne Problem einfach immer erlauben. Oder eben auch nur ein einziges mal. Wie man will. Das einzige problem am unbegrenzten einprogrammieren wäre ein möglicher Known-Plaintext Angriff auf H, wenn man den Schlüssel in den Fingern hätte. Und wenn dann H nicht ganz sicher implementiert ist.... edit: muss mich oben korrigieren. Zero-Knowlege isses natürlich nicht. Könnte man aber machen. Lohnt aber nicht. gruß cyblord
:
Bearbeitet durch User
Danke für den Crypto-Lehrgang! Das hört sich vernünftig an und ist (in den Grenzen von 8K Flash) ja auch ohne Hardware-Erweiterung machbar. Momentan scheitert es nur daran, dass ich nicht einmal das primitiv-Programm in den Chip bringe. Wie war nochmal die Frage? > Spar Dir den Attiny und nimm 1-Wire Chips von Maxim. Diese 3-Beiner haben mich überhaupt erst auf die Idee gebracht. Keine Platine im Stecker und vor allem keine Programmierung, das hat schon was... Aber der 1-Wire-Master in Software war mir viel zu aufwendig und der "Hardware"-Master DS2482-100 macht auch nur die halbe Arbeit. Mehr als 64 Befehle über den I²C-Umweg, nur um den Chip zu adressieren, das kann's doch auch nicht sein. Lieber lerne ich ATtiny zu programmieren.
picaxe könnten fuer dich ev. von Interesse sein, können 1Wire, einfach zu Programmieren, man braucht nur ein RS232 Kabel und relativ Kostengünstig und brauchen nur einen externen Kondensator, die m2 Parts glaube ich brauchst du 08m2. Schau dir die mal an.
gnd3 schrieb: > Danke für den Crypto-Lehrgang! Das hört sich vernünftig an und ist (in > den Grenzen von 8K Flash) ja auch ohne Hardware-Erweiterung machbar. > Momentan scheitert es nur daran, dass ich nicht einmal das > primitiv-Programm in den Chip bringe. Wie war nochmal die Frage? > >> Spar Dir den Attiny und nimm 1-Wire Chips von Maxim. > > Diese 3-Beiner haben mich überhaupt erst auf die Idee gebracht. Keine > Platine im Stecker und vor allem keine Programmierung, das hat schon > was... Aber der 1-Wire-Master in Software war mir viel zu aufwendig und > der "Hardware"-Master DS2482-100 macht auch nur die halbe Arbeit. Mehr > als 64 Befehle über den I²C-Umweg, nur um den Chip zu adressieren, das > kann's doch auch nicht sein. Lieber lerne ich ATtiny zu programmieren. Es scheint mir, Du bist selbst zum Bedienen von Google zu doof. http://www.atmel.com/images/doc2579.pdf Dazu gibts den passenden Quellcode. Du brauchst es nicht einmal abzutippen. Nur das Hirn solltest Du einschalten. fchk
chris schrieb: > picaxe könnten fuer dich ev. von Interesse sein in der Tat, das sind ja richtig fette Teile. Danke! > einfach zu Programmieren, man braucht nur ein RS232 Kabel die PIC die da drin stecken hatte ich eigentlich schon aussortiert wegen zu schwierig zu Programmieren, vielleicht muss ich an meinen Vorurteilen arbeiten... > relativ Kostengünstig naja, nicht einmal das 10-fache vom normalen PIC, aber zum Ausgleich weder bei DigiKey, Mouser, Farnell, Segor, Reichelt oder Conrad erhältlich ;) Besonders nett: Farnell und Segor zeigen "Microcontroller" oder "Arduino" als Suchergebnis für "picaxe" an :) Alleine deshalb kommen sie in die engere Wahl. Frank K. schrieb: > Es scheint mir, Du bist selbst zum Bedienen von Google zu doof. Vielleicht suche ich bei Dallas oder Maxim nach 1-Wire und nicht bei irgendwelchen Fremdherstellern? > http://www.atmel.com/images/doc2579.pdf Danke, sag' ich doch: viel zu kompliziert. Außerdem müsste der Master ja nicht auf dem kleinen Atmel laufen sondern auf einem ARM.
gnd3 schrieb: >> http://www.atmel.com/images/doc2579.pdf > Danke, sag' ich doch: viel zu kompliziert. Außerdem müsste der Master ja > nicht auf dem kleinen Atmel laufen sondern auf einem ARM. Ja und? Wo ist das Problem? Wenn Du einen UART für das Erzeugen der Pulse nutzt, wie es im Paper beschrieben wird, ist das ganze ziemlich unkritisch. fchk
Jetzt gebt ihr euch so viel mühe mit dem Schlüssel - und ich würde lediglich das Schloss bruteforcen...
Marcus W. schrieb: > Jetzt gebt ihr euch so viel mühe mit dem Schlüssel - und ich würde > lediglich das Schloss bruteforcen... Was das Schloss aber ziemlich einfach verhindern kann. Das bestimmt die Geschwindigkeit mit der es neue Schlüssel akzeptiert. Machst 5s pro Schlüssel dann bist du raus. Schon bei 1 sek. Der Schlüsselcode kann ja auch beliebig lang sein, 128 bit, 256, 2048 bit. Kein Problem. Bereitet keine Schmerzen solche Codelängen. Mit Brute Force kommste da nicht weit.
Stimmt! Ich hab die Schlüßellänge nicht bedacht - bei simplen Algorithmen kannst du da kByte drüberschicken... Na dann bastelt schön weiter, Jungs! ;)
um mal auf die eigentliche Frage zurück zu kommen, der aktuelle Spielstand: Microchip 1, Atmel 0 chris, du bist mein Held! (auch wenn der picaxe Tipp evt. nicht so gemeint war). Nach nur einem PIC-Datenblatt und http://picpgm.picprojects.net glaube ich, dass ich den PIC auch selbst programmieren kann. Davor wusste ich von den PIC nur, dass es sie gibt. Seit einem halben Jahr hab' ich sehr viel über Atmel gelesen und wollte ihnen wirklich eine Chance geben -- das Ergebnis sieht man ja :( Das könnte auch die Erklärung sein, warum man hier im Forum viel mehr über Atmel als über Microchip findet -- bei den PIC bleiben kaum Fragen offen.
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.