Restriktive Foren
Das Forum für Keuschheitsgürtel, Fetisch & Bondage

HomeRegistrierenHilfeLogout
Willkommen Gast

Live Diskutieren, auch das ist möglich, hier ist unser Chatraum
  Restriktive Foren
  Keuschheitsgürtel selbstgebaut (Moderatoren: Bulli31)
  Bluetooth Schloss
Thema löschen Druckversion des Themas
Antwort schreiben Bei Antworten benachrichtigen
 Autor Eintrag
esus
Fachmann

Nordthüringen




Beiträge: 77

Geschlecht:
User ist offline
  RE: Bluetooth Schloss Datum:15.06.20 11:56 IP: gespeichert Moderator melden


Das war die falsche Rubrik.
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
fiasko Volljährigkeit geprüft
Keyholder





Beiträge: 201

Geschlecht:
User ist offline
  RE: Bluetooth Schloss Datum:15.06.20 18:27 IP: gespeichert Moderator melden


Moin moin!

Mir ist beim Mitlesen eine Idee gekommen:

Wie wäre es wenn die eingebaute Batterie nur für die Logik zuständig wäre. Und man zum Öffnen ein USB-Netzteil oder eine Powerbank anschließen muß?
Dann wäre zum einen die mögliche Zeit ohne Ladekabel länger, und durch den externen Stromlieferanten eine Öffnungsmöglickeit sichergestellt. Wenn der innere Akku leer ist, läuft im schlimmsten Fall die Zeit nicht weiter....
Wenn man dann auch noch zum Schluss die ganze Schaltung in Harz eingiest, sollte da auch Wasser kaum etwas schaden können.

[Edit]: Dieser Eintrag wurde zuletzt von fiasko am 15.06.20 um 18:28 geändert
Homepage besuchenE-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Mark70
Stamm-Gast

NRW


Verschlossen in lato

Beiträge: 228

Geschlecht:
User ist offline
  RE: Bluetooth Schloss Datum:15.06.20 21:32 IP: gespeichert Moderator melden


Ich bekomme fast alles an Bauteile die ich benötige selbst an Radio Röhren komm ich dran.
Mein Großhändler kommt zum größten Teil Teil sogar an abgekündigte Bauteile ran.
SMD ist nicht mein Ding.
Allerdings gibt es dafür eine Schablone die die Leiterplatten Hersteller für kleines Geld dabei legen.
Es gibt spezielle paste für SMD. Damit wird die Leiterplatte behandelt und die Bauteile mit Hilfe der Schablone aufgesetzt. Dann das ganze kurz auf ne Herdplatte oder im Grill damit. Bei einer bestimmten Temperatur.
Elektor hat dazu mal einen Artikel veröffentlicht.
Ich habe damit zwar keine Erfahrung aber ich würde mich daran wagen.
Theoretisch kann man dann auch den at mega 1280? Einsetzen.
8-Bit-AVR-RISC-basierte Microchip-Mikrocontroller mit geringem Stromverbrauch kombiniert 128-KB-ISP-Flash-Speicher, 8-KB-SRAM, 4-KB-EEPROM, 86 Allzweck-E / A-Leitungen, 32 Allzweck-Arbeitsregister, Echtzeitzähler und sechs flexible Timer / Zähler mit Vergleichsmodi, PWM, 4 USARTs, byteorientierter serieller 2-Draht-Schnittstelle, 16-Kanal-10-Bit-A / D-Wandler und einer JTAG-Schnittstelle für das On-Chip-Debugging. Das Gerät erreicht einen Durchsatz von 16 MIPS bei 16 MHz und arbeitet zwischen 2,7 und 5,5 Volt.
Bevorzugen würde ich aber kleinere Modelle wie den atmega 8 o. Ähnlich je nach dem wieviel Speicher du eben brauchst.

Passende Leiterplatten kann ich dafür machen lassen.
Da sie sowieso klein sind. Ist selbst ein Prototyp nicht so Teuer und noch bezahlbar.

Das Projekt ist auf jeden Fall geil und das Ding kriegen wir bestimmt auch noch strom sparsamer hin. Es reicht wenn die Elektronik für die Verarbeitung eingeschaltet wird über einen Taster und ausschalten tut er sich automatisch wenn er seinen Job gemacht hat. Per Software oder ne555 realisierbar.

Ich habe dir ne PN geschrieben. Allerdings ist diese irgendwie nicht gesendet worden da ich sie nicht im Verlauf sehen kann.
So meine Vermutung.

Würde mich freuen wenn du mir deine Mail schicken könntest.
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Poppler
Fachmann





Beiträge: 47

User ist offline
0  0  
  RE: Bluetooth Schloss Datum:16.06.20 07:47 IP: gespeichert Moderator melden


@Mark70 sicher kannst du auch einen ATMEGA 1280 nehmen. Der ist etwa 10 mal größer und vielfach mehr Hardware drauf. 100 Pins sind mal ne Ansage. Ich denke auf den NE555 (LMC555) kann man verzichten wenn der Taster einfach einen Interrupt ansteuert. Die Prozessoren haben alle gemein einen Stromverbrauch von <1uA im PowerOff. D.h. bei meiner Schaltung würde der Akku dann 5800 Stunden bzw. 15 Jahre halten
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Bulli31
Forum-Ingenieur



Das Morgen gehört denen, die sich heute darauf vorbereiten
¡Átame!

Beiträge: 4259

Geschlecht:
User ist offline
  RE: Bluetooth Schloss Datum:18.06.20 22:36 IP: gespeichert Moderator melden


Hallo Poppler,

sinnvoll könnte es sein den DAC nur nach einer bestimmten Anzahl Rx-Kontakten zu starten. Dann ist der Akku kurz nach einer Belastung am schwächsten. Auch überlappen sich dann die beiden Aufgaben nicht, was zu seltenen Stromspitzen und damit zu besonders tiefen Betriebsspannungen führen kann.

Den ATtiny kann man auch mit dem internem 128 kHz Oszillator betreiben (Watchdog-Oscillator; kalibriert auf 3,0 Volt Betriebsspannung). Gegenüber dem Betrieb mit 1 MHz lässt sich bis zu 90% Energie einsparen. Das funktioniert aber nur, wenn der Code ausreichend wenig Zyklen benötigt.

Wenn ich aber richtig verstanden habe, werden die MCU und das BT-Modul direkt an der Batterie angeschlossen ohne Spannungsregler.

Moderne Spannungsregler verbrauchen bei 650 µA Ausgangsstrom nur um die 6,5 uA im Masseanschluss (Iq; 25nA bis 700µA; TPS7A02). Damit wäre dann die Überlegung möglich, ob es sich lohnt MCU und BTE mit einer niedrigen geregelten Festspannung laufen zu lassen, um Energie einzusparen. Je geringer die Betriebsspanung der MCU, um so geringer die Verlustleistung.

So langsam geht es bei den Verbräuchen in den Profi-Bereich. Da ist die Frage, ob man da noch weiter gehen will.


[Edit]: Dieser Eintrag wurde zuletzt von Bulli31 am 19.06.20 um 13:54 geändert
Viele Grüße
bulli

Aus aktuellem Anlass: . - - - ; . . Infos zum Forum: . Einführung & FAQ & Hilfestellung von A bis Z
Infos zu BDSM und KG allgemein: . Ohrstöpsel | Keuschheitsgürtelumfrage | Anal Plugs | Elektrostimulation | KG in Museen/Museum mit KG
Infos zur CB-Serie: . Material | erlaubte Öle/Crèmes | Risse in Kunststoff kleben | ferngesteuerte Elektroimpulse in CB-Serie

E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Poppler
Fachmann





Beiträge: 47

User ist offline
0  0  
  RE: Bluetooth Schloss Datum:19.06.20 15:06 IP: gespeichert Moderator melden


Hi Bulli,

zur ADC hast Du recht. Die Praxis hat gezeigt, dass ich keine Probleme mit Spitzen und höherem Verbrauch habe. Ich hab jetzt mehr als 20 vollständige Entladungskurven und alle nach Excel exportiert um die Berechnung des Ladezustands machen. Es gab keine Ausreißer und der Batteriestand ist auf +/-3% genau. Ich finde das ist völlig ausreichend. Ich brauche auch keinen "ADC Noise Reduction".

Über den Oszillator hab ich auch nachgedacht. Man will ja Strom sparen Man muss dabei die Taktfrequenz * Aufwachzeit betrachten um die Energie zu berücksichtigen. Die Effizienz ist tatsächlich höher bei höherem Takt. Also man muss sehr schnell wieder schlafen. Aber was viel wichtiger für mich war ist der UART den ich nicht mit 128kHz so einfach zum Laufen bekomme. Aber dein Vorschlag bleibt definitiv auf der Liste der Dinge die man dann noch angehen kann!

Richtig gut finde ich aber deinen Vorschlag mit dem TPS7A02. Ich denke das würde definitiv funktionieren und würde etwas bringen. Man könnte die gesamte Schaltung mit 2V betreiben. Auch der Motor funktioniert bei 2V aber man müsste trotzdem die Kraft nochmal überprüfen. Im Moment hindert mich, dass ich dafür ein PCB bauen müsste. Das könnte man zusammen mit einer eigenen Ladeelektronik machen. Kommt aber auf die "Super Idee" ToDo Liste.

Von meiner Seite ein Update:
1) Ich habe eine Induktionsladeschaltung gefunden und bestellt. Kommt in ca. 8 Wochen. Allerdings scheint sie mit mit 18mmx20mm zu groß als dass ich dafür einen Platz finden werde. Trotzdem hab ich sie bestellt um damit mal Testen zu können.
2) Ich war jetzt langsam am Verzweifeln warum der Batterieverbrauch "so hoch" ist. Ich habe letztendlich auch das komplette BT stromlos gemacht und immer noch war der Verbrauch zu hoch. Kurz gesagt habe ich zum Glück irgendwann mal ein Multimeter genommen und die Pins durchgemessen und dabei einen falschen Pegel entdeckt. Irgendwas Dummes muss es ja sein. Von daher bin ich guter Dinge, dass das der Fehler war. Wenn nicht ist mein Messequipment heute bei der Post angekommen Test läuft und morgen weiß ich mehr.

E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Bulli31
Forum-Ingenieur



Das Morgen gehört denen, die sich heute darauf vorbereiten
¡Átame!

Beiträge: 4259

Geschlecht:
User ist offline
  RE: Bluetooth Schloss Datum:19.06.20 22:46 IP: gespeichert Moderator melden


Zitat
Aber was viel wichtiger für mich war ist der UART den ich nicht mit 128kHz so einfach zum Laufen bekomme.
Hallo Poppler,

du meinst bestimmt nicht, dass du einen Hardware-UART angebaut hast?
Ein Software-UART könnte zu langsam für das BLE-Modul sein, da hast du recht. Das Modul hatte ich mir nicht angesehen.

Vielleicht würde ein ATtiny841 mit integriertem Full Duplex UART funktionieren. Die Aufwachzeiten sind fast identisch. Die Aufwachezit aus dem Reset entspricht der langsamen Aufwachzeit beim ATtiny84A.

Ich bin so alt, ich könnte mir sogar einen selbst programmierten asynchronen 4-Bit-Bus vorstellen, wenn das machbar ist.


[Edit]: Dieser Eintrag wurde zuletzt von Bulli31 am 19.06.20 um 22:47 geändert
Viele Grüße
bulli

Aus aktuellem Anlass: . - - - ; . . Infos zum Forum: . Einführung & FAQ & Hilfestellung von A bis Z
Infos zu BDSM und KG allgemein: . Ohrstöpsel | Keuschheitsgürtelumfrage | Anal Plugs | Elektrostimulation | KG in Museen/Museum mit KG
Infos zur CB-Serie: . Material | erlaubte Öle/Crèmes | Risse in Kunststoff kleben | ferngesteuerte Elektroimpulse in CB-Serie

E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Poppler
Fachmann





Beiträge: 47

User ist offline
0  0  
  RE: Bluetooth Schloss Datum:19.06.20 23:52 IP: gespeichert Moderator melden


Hi Bulli,

der ATTiny841 funktioniert einwandfrei aber wie gesagt ist der UART nur bis 1MHz spezifiziert (S.177). Ich hab's nicht probiert aber vielleicht würde UBRR=3 bei 256kHz gehen
Mir geht im Moment massiv der Speicher aus (120 byte free) deswegen kam ich ohne HW UART nicht mehr aus. Hab schon viele Sachen durch eigene Implementierungen ersetzt, u.A. auch den Uart. Naja, noch geht ja alles.

4-bit Bus klingt ok. Ich bin auf 8-Bit mit AT-Kommandos gegangen. Ein paar Standard und dann ein paar selbst ausgedachte: ATZ, +OK, ATT=120, +OK, ATC, +OK, ATO, -ERR

Sag mal, ich denke ich muss definitiv die Spannung senken, weil ich noch eine Z-Diode in der Schaltung habe und dadurch immer ein Strom fließt (1,5k Pullup). Im Board ist VUSB vorgesehen und deshalb die Schutzschaltung drauf. Ich kann doch ne 1N4148 in Reihe schalten, dann sollte ich 0,6V weniger haben und ich kann weiter die Batteriespannung im Prozessor messen. Oder hab ich da noch einen Fehler? Weil daher kommt mein Stromverbrauch zu Zeit . Aber selbst dann bleiben immer noch ein paar hundert µA übrig. Ich denke ich bau die Z-Dioden aus und hoffe der USB vergibt mir mit den maximal verbleibenden 3,6V.

Schönen Start ins Wochenende



[Edit]: Dieser Eintrag wurde zuletzt von Poppler am 20.06.20 um 21:18 geändert
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Poppler
Fachmann





Beiträge: 47

User ist offline
0  0  
  RE: Bluetooth Schloss Datum:21.06.20 17:02 IP: gespeichert Moderator melden


Update

Nach einem kleinerem Umbau hab ich jetzt ein gutes Ergebnis. Die Software war schon in Ordnung, aber beim Atmel konnte eine Diode entfernt werden.
Jetzt liegt der Verbrauch des Atmels bei 19uA und bei BT bei etwa 25uA. Also ingesamt bei unter 50uA.

Das macht dann bei meinem Akku eine Laufzeit von etwa 2800h bzw. 116 Tagen. Das würde mir dann reichen
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Bulli31
Forum-Ingenieur



Das Morgen gehört denen, die sich heute darauf vorbereiten
¡Átame!

Beiträge: 4259

Geschlecht:
User ist offline
  RE: Bluetooth Schloss Datum:21.06.20 20:11 IP: gespeichert Moderator melden


Hallo Poppler,

schön, dass es so ein Problem war.
Mein nächster Tipp wären Entwicklungsumgebungen für MCU für Wearables gewesen mit eingebauten BLE v5.0.

[Edit]: Dieser Eintrag wurde zuletzt von Bulli31 am 21.06.20 um 22:42 geändert
Viele Grüße
bulli

Aus aktuellem Anlass: . - - - ; . . Infos zum Forum: . Einführung & FAQ & Hilfestellung von A bis Z
Infos zu BDSM und KG allgemein: . Ohrstöpsel | Keuschheitsgürtelumfrage | Anal Plugs | Elektrostimulation | KG in Museen/Museum mit KG
Infos zur CB-Serie: . Material | erlaubte Öle/Crèmes | Risse in Kunststoff kleben | ferngesteuerte Elektroimpulse in CB-Serie

E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Poppler
Fachmann





Beiträge: 47

User ist offline
0  0  
  RE: 4. Prototyp Datum:25.06.20 18:14 IP: gespeichert Moderator melden


Der vierte Prototyp wird auch langsam fertig:



3mm in der Höhe eingespart und ich denke die Mechanik ist deutliche robuster geworden. Das Schloss ist jetzt 12 mm hoch und wenn man es in die Halterung eingesetzt, ragt es noch 7 mm oben hinaus.

Da der Akkuverbauch jetzt sehr niedrig ist.. Nach mehreren Tagen sind es etwa 5% Akkuverbrauch. Also sind 1 Monat Standby kein Problem mehr.

Gruss,
Poppler
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Poppler
Fachmann





Beiträge: 47

User ist offline
0  0  
  RE: Bluetooth Schloss Datum:11.07.20 00:55 IP: gespeichert Moderator melden


Nach zwei Wochen mal ein Update..

Ich habe den vierten Prototyp in Auftrag gegeben und hoffe ihn in einer Woche zu bekommen. Inzwischen sind auch neue Zahnräder aus Metall gekommen und ich habe eine neue Ladeelektronik die ein paar Millimeter kleiner ist



Ansonsten habe ich weiter an der Software gearbeitet. Zwei kleinere Fehler waren noch im Program des Schlosses die ich behoben habe. Die Android App habe ich inzwischen weiterentwickelt und auch die PIN Funktion vervollständigt. Ich habe jetzt auch die Unterstützung mehrerer Schlösser hinzugefügt und dabei einige Fehler gefunden, da dieses ständige Umschalten ein ziemlich Stress für das Programm ist. Inzwischen geht's ganz gut



Den Namen vom Schloss kann man jetzt auch verändern. Als nächstes kommt die letzte Funktion in der ich die Einmalschlüssel implementiere. D.h. das Schloss kann maximal 6 Einmalschlüssel (8 Stellig alphanumerisch) generieren, die dann zu jedem Zeitpunkt das Schloss öffnen können. Das in Kombination mit der Handy-App (über die die Schlüssel ja zu bekommen sind) ergeben sich unzählige Möglichkeiten. Der Vorteil, diese lassen sich dann in der App realisieren und nicht über das kleine Schloss.

Erfahrungen so weit. Ich habe kleine Zähler und Messungen in das Schloss eingebaut. Mein Prototyp mit dem ich am meisten Test hat jetzt 240 Öffnungen & Schließungen. Der Akku verhält sich weiterhin gut. Nach 14 Tagen sind trotz sehr häufigem benutzen etwa 17% Akku verbraucht. Also weiterhin 2 Monate nutzbar bevor der Akku geladen werden muss. Keine Abstürze, Hänger oder ähnliches. Ich bleibe weiter optimistisch
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
private_lock Volljährigkeit geprüft
Staff-Member

Braunschweig


Jedes Schloss ist ein Meta-Konsens!

Beiträge: 3982

Geschlecht:
User ist offline

206318797  206318797  206318797  206318797  private_lock  
  RE: Bluetooth Schloss Datum:18.07.20 12:48 IP: gespeichert Moderator melden


Hallo Poppler!

Zunächst ziehe ich meinen Hut vor Dir, dass Du einen Prototypen zum Laufen gebracht hast. Das ist deutlich mehr, als wir anderen (ich eingeschlossen) aufgebracht haben - außer vielen schönen Worten. Sei also bitte nicht verstimmt, wenn ich trotzdem nicht ganz glücklich mit dem Design bin

Was ich glaube verstanden zu haben:

  1. Dein Verschluss funkt permanent über Blutooth?
  2. Es gibt keine Authentifizierung - jedes Handy in Reichweite kann sich daran koppeln?
  3. Im Schloss läuft ein Timer - durch einen einfachen unverschlüsselten Befehl kann Zeit hinzugefügt werden bzw. der Timer bis zum Ablauf versteckt werden, so dass er nicht mehr ausgelesen werden kann?
  4. Ebenfalls unverschlüsselte Einmal-Codes erlauben am Timer vorbei einen sofortigen (Nofall-)Aufschluss?


Als KG-Träger würde ich nicht mit einem T-Shirt rumlaufen, dass mich als KG-Träger outet ... warum sollte ich mir also das elektronische Äquivalent dazu in die Hose bauen? Für eine Story sicher nett: "Der KG-Träger betrat das Café und auf den Handys der anwesenden Damen poppte eine Meldung auf: Herrenloser Keuschling - Möchten Sie jetzt eine Verschlusszeit festlegen?"

Andersherum formuliert würde ich mir wünschen, dass im Schloss z.B. kryptographische Zertifikate hinterlegt werden, die ein oder zwei Handys eindeutig identifizieren und alle anderen stillschweigend abweisen. Überhaupt wäre es wünschenswert, wenn der KG vollkommen passiv lauscht und erst sendet, wenn er etwas zu sagen hat - d.h. nach Empfang einer authentifizierten Statusabfrage / einem Update-Befehl für die Zeit.

Als zweiten Kritikpunkt missfällt mir leider die Fixierung auf Zeit allein. Für den Solo-Keuschling mag es immer nur um Stunden gehen. Aber mit einer Schlüsselhalterin entsteht ein wesentliches Spannungsmoment aus Ihrer Willkür (sowohl bei Ablauf der Uhr trotzdem nicht zu öffnen, weil sie gerade eine Stimmungsschwankung hat aber auch vor Ablauf der Uhr Gnade walten zu lassen). Mit Deinem Setup könnte sie in schlechter Laune sein und Dir einen Monat Dauerverschluss aufbrummen. Der Haken ist, dass sie es sich anschließend nicht mehr anders überlegen kann - Das Privileg der Damen: Ihre Meinung zu ändern ...

Da würde ich mir wünschen, dass sie auf Ihrem Handy die volle Kontrolle hätte: Also den Timer vor dem KGT verstecken ist OK, aber niemals vor der SH. Und wenn eine "Mindest-Zeit" gesetzt wird, ist die für den KGT bindend, aber niemals für die SH: Sie bekommt allenfalls eine Rückfrage, die sie wegklicken kann, um dann trotzdem die Mindest-Zeit zu verkürzen.

Bei so einem Setup mit zwei Handys von SH und KGT öffnet sich eine völlig neue Welt, etwa wenn sie eine codierte und signierte Öffnungserlaubnis per Text-Nachricht schickt, die er dann kopiert und in seine App einfügt. Es könnte ein sofortiger Aufschluss im Büro sein - gültig nur innerhalb von 5 Minuten oder er muss ein Spiel ausführen und gewinnen mit entsprechenden Zuschlägen oder Abzügen auf seine Restlaufzeit. Jede Zeitänderung, die seine App an das Schloss sendet, müsste sich am besten online und direkt bei Ihrer App eine Bestätigung holen, so dass auf Ihrem Handy auch außerhalb der Blutooth-Reichweite zuverlässig der Stand des Timers nachvollzogen werden kann.

Der Bedarf, die Verschlusszeit zu verfolgen und eine mögliche "zukünftige Öffnung" als Karotte an der Angel vor seiner Nase baumeln zu lassen, ist sicherlich gegeben. Nur darf es eben nicht sklavisch allein um das Verrinnen von Zeit gehen, denn das ist die Definition von Langeweile. Erst die Zustandsänderung macht die Keuschheit interessant. Und wenn man der Schlüsselhalterin schon den Namensgebenden Schlüssel wegnimmt, sollte sie einen adäquaten Ersatz in die Hand bekommen.

LG
private_lock
private_lock - Les 3 côtés d'un SwItCh: TOP & sub

KGForum im Firefox

Infos zum Forum: Einführung - FAQ - Hilfestellung von A bis Z
Homepage besuchenE-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Poppler
Fachmann





Beiträge: 47

User ist offline
0  0  
  RE: Bluetooth Schloss Datum:19.07.20 12:01 IP: gespeichert Moderator melden


Hallo private_lock,

erst einmal vielen Dank für das positive Feedback. Es freut mich seht wenn ich konstruktive Kritik bekomme

Erstmal muss ich zu ein paar technischen Einschränkungen kommen. Mit der gegebenen Hardware kann ich definitiv nicht ein Verschlüsselung umsetzen. Also nichts was Ersthaft wäre. Das sind ganz andere Dimensionen von denen wir da sprechen. Ich habe nur 6500 Zeichen für das gesamte Programm. (Dieser Thread hat schon mehr )

Zur Sichtbarkeit des Gerätes: Also bis auf den Namen den man verändern kann, ist das Schloss erstmal unauffällig. Man kann also aus irgendwelchen Werten wie MAC oder so nichts erkennen. Aber gut das muss jeder entscheiden. Das das Gerät sichtbar ist liegt einfach am Bluetooth-LE Standard. Also man müsste die komplette Firmware des BT neu entwickeln. Wir sprechen jetzt langsam von zig-tausend Euro Entwicklungskosten.

Wo du definitiv recht hast ist, dass ich erstmal an Solo-KG-Träger gedacht habe und gerade deshalb finde ich deine Meinung so wichtig. Dazu möchte ich folgendes mal einwerfen:

Die wichtigsten Funktionen sind tatsächlich der Timer und die PINs. Die erste Funktion die vom SH erstmal gemacht werden müsste ist den PIN zu vergeben. Ohne diesen PIN läßt sich das Schloss schon mal gar nicht mehr kontrollieren. Es gibt also auch keinen Grund mehr eine Mindestzeit via Timer einzustellen. Dem KGT kann jetzt nur noch ein Einaml-PIN "helfen". Alles andere z.B. Funktionen wie Remote freischalten usw. lassen sich alles in der App regeln. Letztendlich wird die App allerdings immer die "Genehmigung" des Schlosses brauchen/anfragen, d.h. die App zu hacken würde jetzt nicht helfen. Bei falscher PIN Eingabe startet das Schloss automatisch den Timer um ein Hacken zu vehindern.

Sprich die Grundidee ist die lustigen Funktionen nur in der App zu realisieren und das Schloss aufgrund der techischen Einschränkungen auf ein Minimum zu belassen.

Erklärt das meine Idee einigermaßen?

Danke nochmal,
Poppler
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
private_lock Volljährigkeit geprüft
Staff-Member

Braunschweig


Jedes Schloss ist ein Meta-Konsens!

Beiträge: 3982

Geschlecht:
User ist offline

206318797  206318797  206318797  206318797  private_lock  
  RE: Bluetooth Schloss Datum:20.07.20 21:37 IP: gespeichert Moderator melden


@Poppler

Meine naive Annahme war, dass Blutooth als moderne Schnittstelle doch bestimmt mit eigenen Verschlüsselungsalgorithmen daher kommt. Aber das ist wohl alles in einem eigenen Modul weggekapselt?!?

Folglich hat die Uhr im Schloss nichts mehr mit der eigentlichen Verschlussdauer zu tun? D.h. wer die richtige PIN kennt, kann das Schloss öffnen, egal welche Zeit die Uhr zeigt? Warum dann überhaupt eine Uhr ... es sei denn: Du benutzt die Uhr nur, um z.B. zyklisch die gerade gültigen Einmal-PINs zu aktualisieren, wie etwa ein "linear rückgekoppeltes Schieberegister".

Da könnte man sich z.B. alle x Minuten einen aktuellen neuen Schlüssel R1 generieren, der eben nur für x Minuten direkt gültig ist. Und wenn die Uhr nicht allzu schief läuft, dürft man auch nach Monaten noch das zuständige x-Minuten-Intervall treffen können. Zusätzlich ließen sich einfach die letzten y Schlüssel merken (R2-Ry), die dann ebenfalls gültig sind und eine Öffnung erlauben, wobei R1 immer das jeweilige Ry überschreibt und somit der älteste Schlüssel vergessen wird.

Das Geheimnis der SH bestünde dann darin, den Zustand R1 des Zufallszahlengenerators auf die Minute genau vorhersagen zu können. Damit Subbie aber nicht heimlich nach einer erlaubten Öffnung den aktuellen Zustand R1 des Zufallszahlengenerators kennt, würde man die nackten Werte z.B. durch XOR mit einem zweiten festen Schlüssel-Wert K verfremden. Das wird vielleicht keiner wissenschaftliche fundierten Kryptoanalyse standhalten, aber für den Zweck am KG scheint mir das sicher genug und vor allem mit minimalem Hardware-Einsatz leicht zu berechnen.

Die SH startet also im offenen Zustand des Schlosses (das kannst Du doch hoffentlich in Software erfassen, ob gerade offen ist?) die Verschlüsselungssequenz, indem ihre App den zufälligen Schlüssel K für das XOR sendet. Darauf können im Schloss wie auch in der App die Zufallszahlengeneratoren synchron aber ohne weitere Kommunikation loslaufen. Wird das Handy der SH ausgeschaltet, muss es eben mitzählen, wie viele Zufallszahlen-Berechnungsschritte seit dem Zeitpunkt der Initialisierung nötig sind, um den aktuellen Minuten-Schlüssel R1 abzuleiten. Selbst bei x = 1 Minute sollten die 1440 Operationen pro Tag ein modernes Handy nicht zum schwitzen bringen.

Erlaubt die SH eine Öffnung, kann sie das Alter des Schlüssels Ri aus (R1..Ry) wählen und damit den Ablauf in Schritten von x Minuten für die nahe Zukunft festlegen - ist der KGT nicht schnell genug, hat er Pech gehabt und der Schlüssel ist verfallen, da im Schloss durch einen neuen Wert überschrieben (oder sie wählt alternativ einen "Tease-Schlüssel" T, der nur Datensalat ist und vom Schloss abgewiesen wird, da garantiert ungleich der nächsten Ri für i in -y .. +y). Die SH sendet dann: C = gewählter Zufallswert Ri XOR Schlüssel K. Da subbie K nicht kennt, kann er nicht auf den aktuellen Zustand des Zufallszahlengenerators schließen.

Bei mehreren erlaubten Aufschlüssen könnte Subbie die exakten Zeitpunkte Tn und Cn vermerken und versuchen das Schloss alle paar Minuten mit C zu öffnen, um den exakten Zeitpunkt des Ablaufens zu erfahren. Daher sollte das in C steckende Ri nach einmaliger Benutzung zur Öffnung direkt durch 0 überschrieben werden (der einzige Wert, der garantiert nicht aus dem Scheieberegister kommt und damit immer ein ungültiger Schlüssel). Subbie müsste also alle Paare von Werten des Zufallszahlengerenators mit einem Abstand (Tn-Tm+-x*y Minuten) mit XOR verwursten und sehen, ob irgendwo das gleiche K rauskäme - das wäre erst ab n >= 3 möglich und erfordert ein Programm zum durchprobieren. Daraus folgt, dass die SH sparsam mit der Remote-Öffnung umgehen sollte. Falls das ein Problem darstellt müsste K ebenfalls durch ein Schieberegister bei jeder erfolgreichen Öffnung weitergeschaltet werden. Die App der SH hält dann verschiedene alte K bereit, falls subbie eine Öffnung verpasst hat und kann somit ein anderes Rj != Ri senden und es mit einem älteren K verschlüsseln, um zu sehen, ob das Schloss es akzeptiert. Zusätzlich müsste die App bei der SH nachfragen, ob sie z.B. am Telefon eine Bestätigung bekam, dass der zuletzt freigegebene Schlüssel zum Erfolg führte.

Weiter würde die App der SH bei einer direkten Öffnung ohne Umweg über das Handy des KGT im Anschluss grundsätzlich immer ein neues K setzen und damit die weitere Analyse von K vereiteln. Fragt sich, ob der Aufwand gerechtfertigt ist, die Übertragung von K im Klartext zu verhindern, etwa durch einen Diffie-Hellman-Schlüsselaustausch. Sub könnte den Austausch über die Funkschnittstelle andernfalls mitlesen!?!

Tja, soweit meine Krypto-Wünsche runtergebrochen auf die Möglichkeiten Deines Chips
private_lock
private_lock - Les 3 côtés d'un SwItCh: TOP & sub

KGForum im Firefox

Infos zum Forum: Einführung - FAQ - Hilfestellung von A bis Z
Homepage besuchenE-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Poppler
Fachmann





Beiträge: 47

User ist offline
0  0  
  RE: Bluetooth Schloss Datum:21.07.20 13:20 IP: gespeichert Moderator melden


@private_lock,

das normale Bluetooth hat eine Verschlüsselung eingebaut und wird auch über Authentifizierung gegen einen Verbindungsaufbau geschützt. Bei BluetoothLE ist das nicht so. Deshalb kann ich auch bei anderen Bluetoothgeräten mithören und beispielsweise die TENS Geräte ansteuern.

Also die Uhr hat direkt was mit dem Verschluss zu tun. Die Grundfunktion ist, dass man per Bluetooth das Schloss öffnen und schließen kann. Ist ein Timer gesetzt kann man es nicht mehr öffnen. Ist ein PIN gesetzt kann man es nicht öffnen solange nicht der PIN eingeben und die Zeit abgelaufen ist. Die weiteren Kommandos können wir mal an dieser Stelle ignorieren. Jetzt kommen noch die Einmal-PINs die dann den PIN und den Timer umgehen sollten. Warum sollten? Weil ich da im Moment einen Fehler drin habe den ich noch irgendwie beheben will. Mein Problem ist, dass ich nur noch 27 Bytes Speicher frei habe und meine Lösung zu kompliziert ist um sie in 27 Bytes noch unterzubringen... Also das ist so das aktuelle Problem. Über eine Verschlüsselung brauche ich bei der Hardware nicht nachzudenken.

Aber die Idee ist richtig und gut. Vielleicht will Mark70 diese aufgreifen, weil er ja mit einem viel größeren Prozessor spekuliert. Wenn man ein paar KB Speicher mehr hat könnte dein Vorschlag definitiv funktionieren.

Noch eine Sache am Rande. Die Zeitbasis ist ein echtes Problem. Die Uhrzeit des Controllers weicht von der echten Zeit ab. Die Hardware hat zwar eine Kompensation der Temperatur und Betriebsspannung aber trotzdem hab ich immer noch Abweisungen von ca 2%. Ich weiß noch nicht genau wie ich das Lösen werde. Ich könnte zwar den Takt anpassen, aber dann würde die UART Verbindung zum BT Chip nicht mehr funktionieren. Dann müsste ich den UART ohne Hardwareunterstützung von Hand schreiben, aber dann passt das Programm nicht mehr in den Speicher. Andere Lösung wäre die Spannung zu spabilisieren, aber dann könnte ich die Spannung nicht mehr messen weil ich wieder keinen Eingang am Chip frei habe.. Im Moment versuche ich auch das Zeitproblem innerhalb der App zu kaschieren.

Poppler
E-MailProfil anzeigenNachricht senden Nachricht kopieren Nachricht zitieren Nachricht �ndern Nachricht l�schen
Seiten(2) «1 [2] »
Antworten Bei Antworten benachrichtigen
Jumpmenü
Google
Suche auf dieser Seite !!


Wir unterstützen diese Aktion

Impressum v 1.2
© all rights reserved, 2020

Status: Sessionregister
Der Aufruf erzeugte 23 locale und 1 zentrale Queries.
Ladezeit 0.04 sec davon SQL: 0.02 sec.