Wo das Thema synchronisation schon mal da ist…
Jetzt Android lastig, es geht um Backup und/ oder sync von SMS und Anruflisten des Android devices.
Wobei für mich persönlich der Clou an der Sache ist, dass das Backend ein beliebiges IMAP-Konto ist,
und das Format sogar Menschenlesbar.
All diese schönen Features bring die Software SMS Backup + ( Market link ).
Installation und Configuration sind eigentlich relativ gerade aus, wenn man einige Fallstricke kennt.
Continue reading
Mal wieder das alte Leid, Syncronisation.
Heutige Episode: Calendar Sync und Contact Sync.
So etwas wie iCloud oder Google Calendar bzw Google Contacts, aber die Daten bitte beim Besitzer lassen.
Clients: Android Telefon, Linux& Mac Desktop
(theoretisch sollte auch iPhone möglich sein, habe ich allerdings mangels Gerät nicht getestet)
Insgesammt kommen zwei offene Standarts zur Anwendung. Es wird Caldav bzw. Carddav verwendet.
Als Serversoftware ist lediglich ein Stück PHP Code mit Datenbank (Mysql) nötig ( Sabredav ) (sql-lite ist alternativ auch möglich).
Das ganze ist Serverseitig relativ anspruchslos, im Prinzip braucht es nur php und mysql, daher sollte die Software bereits auf einem simplen und günstigen Webhostingpaket laufen.
Auf den Clients kommt unterschiedliche Software zum einsatz:
Der Mac bringt die Software bereits von Hause aus mit (iCal und Adressbuch),
Unter Linux verwende ich Thunderbird mit lightning für den Kalender, und KAddresssBook (KDE) für Kontakte.
Auf dem Android verwende ich CalDav und CardDav Sync Adapter ( ja die kosten ein paar Euro, funktionieren bei mir aber wirklich sehr gut).
Aber zurück zum Server
Das Setup gestaltet sich sehr simpel.
Erst mal Runterladen der PHP dateien, zu finden hier.
Danach kanns losgehen:
Im SabreDav-Archiv befindet sich ein Ordner mit Namen “examples”, in dem die Datein calendarserver.php und addressbookserver.php. Diese am besten in den Hauptordner kopieren, und dort anpassen.
Die Anpassungen sind sehr minimal:
date_default_timezone_set('Canada/Eastern'); |
wird zu
date_default_timezone_set('Europe/Berlin'); |
Nachdem die Idee mitlerweile schon einiges an Tagen auf dem Buckel hat,
ist die Umsetzung etwas vorrangeschritten und es existiert ein Prototyp.
Er besteht quasi nur aus einem AVR ATMEGA8, der sowohl die Prüfsumme (konkret einen SHA-256) über das Secret berechnet, als auch zum PC hin USB spricht.
Konkret meldet er sich als Tastatur gegenüber dem PC und kann dadurch sehr simpel und quasi überall die Prüfsumme auf den PC übertragen.
Auf der PC Seite (auf dem die Tokeneingabe verifiziert werden soll), existiert derzeit ein PAM-Modul, welches die eigaben des Tokens prüfen kann.
Als nächste Schritte steht jetzt an,
das ganze nicht nur funktionstüchtig, sondern auch ordnetlich umzustezen:
den Schaltplan (der dank eines guten Eagle-Vortrags existiert) in ein ätzbares, möglichst USB-Stickartiges Layout zu verwandelen
und den Source-Code zu struckturieren.
Aus spielerrei Gründen, und weil mich die Technik interessiert,
kam mir neulich die Idee mir selber ein Token (kleines Stück Hardware) zu bauen, welches “Einmalpasswörter” zum Login erzeugt.
Genauer soll es ein Baustein werden, der per USB eingesteckt wird, und auf Knopfdruck ein “Einmalpasswort” an den PC übergeben wird.
Das “Einmalpasswort” soll eine Kombination aus Zeichen sein, die von der Gegenseite verifiziert werden kann, und nur für eine Verwendung gültig ist.
Soviel als generelle Einleitung, auf zur eigentlichen Umsetzungsidee:
Die Idee ist, dass sowohl der Token, als auch die Gegenstelle ein Geheimnis teilen (als Beispiel “geheim123”) . Dieses Geheimnis muss vor der ersten Verwendung einmal über einen sicheren Weg ausgetauscht werden.
Danach werden Einmalpasswörter erzeugt, indem eine Prüfsumme (Hash) über das Geheimnis erstellt, und das Geheimnis selber auf ein festgelegte Art verändert wird (z.B. die letzte Stelle hochgezählt).
HASH("geheim123") ----> 576aa4c2e8948b2a10d21617d3a84085 |
Diese Ziffernfolge wird dann übertragen, die Gegenseite bildet ebenfalls den Hash über das Geheimnis und Prüft ob der übermittelte String übereinstimmt.
Im Anschluss wird das Geheimnis auf beiden Seiten verändert, z.B. zu “geheim124”.
Dies führt zu einem neuen Hash
HASH("geheim124") ----> 3942664d5ea817efbdbbd603b5521d6a |
dieser wäre dann das zweite Einmalpasswort, und so weiter.
WICHTIG zum Thema Sicherheit !
Das hier beschriebene ist einfach nur eine Idee von einem Laien.
Es gibt keinerlei Grund zu der Annahme das das Verfahren als “Sicher” angesehen werden kann. Soll das Verfahren “Sicher” sein, dann sollte dringend etwas gewählt werden, dass mehrfach von Spezialisten reviewd wurde. Das RFC 4226 spzifiziert z.B. so etwas (ganz ähnlich zu der Idee hier).
Ich persönlich sehe das Ganze vorallem als Lernprojekt, und werde es nur zusätzlich zu einem herkömlichen Passwort verwenden (welches ich vorher allein verwendet habe).
Ein Ticket, alle Züge, 25 Tage, einziges Ziel: Deutschland erkunden via Zug.
Erstes Ziel, Meer !
Start ist heute, Richtung ist Hamburg.
Danach über Lübeck an die See.
An den Strand,
Sand zwischen die Füße,
Salz in der Luft riechen und Wellen betrachten.
Die Vorfreude steigt :)
Die Posts der Reise werden in der Kathegorie In 25 Tagen durch Deutschland – Zug um Zug zu finden sein.