Ich habe auf eBay folgenden Artikel gefunden OpenKubus AT90USB646 http://www.ebay.de/itm/OpenKubus-AT90USB646-USB-AVR-Development-64kB-Stick-/251221766606?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3a7dfbf1ce Nun wollte ich dieses Stick dazu benutzen um eventuell 1 KByte Daten auf dem Stick abzuspeichern. Das sollte das Problem nicht sein, doch möchte ich mit einer Windowssoftware diese Daten auch wieder lesen können. Auch dieses müsste damit doch gehen ABER. Ist es möglich das kein anderer meine Daten liest. Also das Teil als eine art Dongel zu benutzen? Treiber kann ich keine schreiben, bräuchte ich da einen?
Wenn Du das Teil selbst proggen kannst, dann mache das doch so: - Mass Storage Device - PC schreibt eine Datei "Lizenz.lic" - Prozessor schreibt die Datei auf den Stick, codiert jedoch die Daten - Beim Lesen decodiert Dein Stick die Daten und gibt die decodierten zurück - Löschen gesperrt Somit, wenn jemand die Datei auf einen anderen USB Stick kopiert, so ist die zwar vorhanden, aber wohl unbrauchbar, da der normale USB Stick die Daten nicht codiert/decodiert. oder mache ein CDC und mit spreche das ganze mit libusb an.
Wende dich bei Fragen doch erstmal ganz einfach an die Projekthomepage http://code.google.com/p/openkubus/
Knipex schrieb: > Ist es möglich das kein anderer meine Daten liest. Wie kann der Stick erkennen, dass er an deinem Windows hängt und nicht an einem anderen Rechner? Ich denke, der Host (PC) wird sich an deinem Stick nicht vorher irgendwie besonders anmelden (z.B. mit einem Passwort)? Was hindert jemanden, das Verhalten deines Windows-Rechners mit einem (z.B. Embedded) System 1:1 nachzubilden? Wenn der Stick (irgendwie) eindeutig erkennen kann, dass er an deinem Rechner hängt, dann kann er auch verhindern, dass die Daten ausgeliefert werden, wenn er deinen Rechner nicht erkennt. Dann kann natürlich immer noch jemand Dritter, der deinen Rechner bedient, auf den Strick zugreifen... Oder man könnte vielleicht auch (irgendwie) direkt auf deinen Stick zugreifen und das interne Flash des uC auslesen (ob das jetzt Sinn macht und man damit überhaupt an die Daten bekommt, weil nicht verschlüsselt, sei jetzt mal dahingestellt). Markus Müller schrieb: > - Prozessor schreibt die Datei auf den Stick, codiert jedoch die Daten > - Beim Lesen decodiert Dein Stick die Daten und gibt die decodierten > zurück Das hab ich noch nicht verstanden... Beim Schreiben verschlüsseln, beim Lesen entschlüsseln, ok, dann sind die Daten nicht aus dem Flash des uC lesbar. Das Ver-/Entschlüsseln ist dann für den PC transparent. Warum kann die Datei auf dem USB Stick dann nicht vom PC gelesen oder auch auf einen anderen Stick kopiert werden? Und dem PC sollte es dann erst einmal egal sein, ob die Daten vom richtigen oder falschen USB Stick kommen? Markus Müller schrieb: > oder mache ein CDC und mit spreche das ganze mit libusb an. Das "Besondere" an CDC ist, dass Windows bereits einen Treiber mitbringt, so dass nur noch ein INF-File benötigt, damit der (virtuelle) serielle Port angelegt wird. Daraufhin kann man mit jedem Programm darauf zugreifen, welches serielle Ports unter Windows bedienen kann (und nicht auf bestimmte COM-Ports limitiert ist). Welchen Sinn macht es hier, statt dem Treiber libusb-win32 zu benutzen? (Ich hoffe, du hattest libusb-win32 gemeint?) Anders, wenn ein proprietäres Interface implementiert wird. Dann gibt es (evt. per Default) noch keine Treiber und man kann libusb-win32 (als Treiber) benutzen, um damit das proprietäre Interface zu bedienen. Aber auch das bietet keinen Schutz, dass nicht jemand anderes den Stick ansprechen kann, weil mittels einfacher USB Tools (usbview) das Interface angezeigt werden kann und solch ein Treiber auch von einem Dritten leicht erzeugt werden kann. @Knipex: Du könntest die Daten natürlich nur im RAM des uC ablegen. Solange der "USB Stick" Spannung hat, bleibt der Inhalt gespeichert. Zieht man den Stick ab oder wird der PC aus geschalten (vorausgesetzt der USB Port ist dann spannungslos), dann ist der Inhalt (möglicherweise) weg. Vielleicht ganz hilfreicher Artikel: http://www.heise.de/newsticker/meldung/29C3-Wenn-der-USB-Stick-luegt-1775128.html Auszug daraus: "Beispielsweise greifen Windows-PCs gleich neun Mal auf den MBR des USB-Sticks zu, Linux-Distributionen sind über ihren Automounter unterscheidbar. Ein solches Verhaltensmuster kann der USB-Stick registrieren und demgemäß die Daten ausspielen, die der Eigentümer preisgeben will." Dies bedeutet aber erst einmal nur einen Unterscheidung, ob Windows da ist oder nicht, noch nicht, ob PC1 oder PC2 mit selber Windows Version zugreift. Ob man dies weiter verfeinern kann, und damit dann doch noch die PCs unterscheiden kann, kann ich nicht sagen.
Danke für die Antwort, sehr ausführlich. Bin halt am überlegen wie ich mit so einem Teil einen Dongel realisieren kann. PC senden an den µC ein Anfrage. Nur bei richtiger Anfrage bekomme der PC einen Antwort (EEprom inhalt). µC darf sich nicht auslesen lassen. Das ganze natürlich nicht über Virtuelle RS232 damit kein Sniffer zwischen PC-Programm uns µC geschaltet werden kann. Treiber schreiben kann ich nicht. Deswegen meine Frage ob das mit diesem Kerl realisierbar ist?
>Das ganze natürlich nicht über Virtuelle RS232 damit kein Sniffer >zwischen PC-Programm uns µC geschaltet werden kann. Dann nimmt derjenige halt einen anderen Sniffer. Du kannst nicht verhindern, das jemand an irgendeiner Stelle den Datenverkehr mitschreibt.
Asymmetrische Krypto ist dafür nicht nötig, das wäre totaler Overkill. Es reicht ein einfaches Challenge-Response-Verfahren: http://de.wikipedia.org/wiki/Challenge-Response-Authentifizierung
Man muss ja nicht unbedingt einen Virtuellen COM Port mit CDC aufbauen, man kann auch ein Custom Device Context daraus machen und dann werden die Endpoints manuell angesprochen.
Hier eine Aufstellung, was es derzeit alles über USB standardisiert gibt: http://www.usb.org/developers/devclass_docs
vielleicht wirst du hiermit glücklich(er) http://www.ftdichip.com/Support/Documents/DataSheets/DLP/dlp-d-dsv12.pdf
Aus den Antworten lese ich also ein NEIN auf meine ursprüngliche Frage. Ob das mit dem AT90USB646 zu realisieren ist ohne eigenen Treiber für den PC schreiben zu müssen.
Du müsstest mal konkreter beschreiben, was Du genau schützen bzw. erreichen möchtest. Möchtest Du, dass man den Dongle nicht klonen kann? Dann muss er ein Geheimnis besitzen, dass er nicht verrät, aber gegenüber der PC-Software nachweisen kann, dass er es kennt. Das geht mit einem Challenge-Response-Verfahren. Oder möchtest Du Daten auf dem Dongle unterbringen, deren Inhalt nur die PC-Software lesen kann? Dann müssen die Daten verschlüsselt vom Dongle gesendet werden und in der Software entschlüsselt werden. Das geht mit jedem normalen USB-Stick, auf dem man eine verschlüsselte Datei speichert. Wenn Du beides willst, dann musst Du eben beides kombinieren: Erst prüft die PC-Software per Challenge-Response, ob der Dongle nicht geklont ist, und danach liest sie die verschlüsselten Daten. Du kannst auch noch mehr machen, z.B. für jede Übertragung einen neuen Schlüssel aushandeln. Das hängt aber alles davon ab, was überhaupt das Ziel ist. Wie Du die USB-Übertragung abwickelst, hat damit nichts zu tun. Das einfachste wäre eine virtuelle serielle Schnittstelle oder ein Massenspeichergerät. Dazu brauchst Du keine extra Treiber.
Knipex schrieb: > PC senden an den µC ein Anfrage. > > Nur bei richtiger Anfrage bekomme der PC einen Antwort (EEprom inhalt). > > µC darf sich nicht auslesen lassen. > > > > Das ganze natürlich nicht über Virtuelle RS232 damit kein Sniffer > > zwischen PC-Programm uns µC geschaltet werden kann.
Knipex schrieb: > Aus den Antworten lese ich also ein NEIN auf meine ursprüngliche Frage. > Ob das mit dem AT90USB646 zu realisieren ist ohne eigenen Treiber für > den PC schreiben zu müssen Das hat keiner behauptet. Du musst nur den Datenverkehr zwischen deinem Programm und dem µC ordentlich verschlüsseln. USB kann man selbst nit einfachen Software-Sniffern mitschneiden, das ist unabhängig von Treiber, Protokoll usw. Und wenn du LibUSB oder WinUSB nimmst, brauchst du auch keine Treiber programmieren kannst aber auf die Endpoints zugreifen ohne CDC oder MSD emulieren zu müssen.
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.