ATtiny45 Programmier-Service?

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?

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...

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

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.

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

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

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! ;)