Skip to content

4096bit RSA Keys mit OpenPGP 2.1 Smartcards

Ich bereite die Einführung einer PGP PKI vor. Dazu habe ich mir ein paar Crypto Hardware Artikel beschafft und werde hier meine Erfahrungen verbloggen. Anfangen möchte ich mit den OpenPGP 2.1 Cards (von Zeitcontrol via Cryptoshop). Die Karten lassen sich direkt in dem connected Smart Card reader meines betagten Dell Latitude E6510 unter Windows 7 ansprechen. Dabei kommt der eingebaute Broadcom Reader zum Einsatz:

c:\Program Files\OpenSC Project\OpenSC\tools>opensc-tool -v -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             Broadcom Corp Contacted SmartCard 0
     3b:da:18:ff:81:b1:fe:75:1f:03:00:31:c5:73:c0:01:40:00:90:00:0c CryptoStick v1.2 (OpenPGP v2.0)

c:\Program Files (x86)\GNU\GnuPG>gpg2.exe --card-status
Application ID ...: D27600012401020100050000xxxx0000
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 0000xxxx
Name of cardholder: Bernd Eckenfels
Language prefs ...: en
Sex ..............: männlich

Läßt sich also ohne Probleme sowohl mit OpenSC 0.15.0 Win64 sowie GnuPG 2.0.29 (GPG2Win 2.3.0) ansprechen. Ich konnte mit dieser Kombination auch 3072bit RSA Schlüssel erstellen und nutzen. Problematisch wird es allerdings wenn man 4096bit RSA Schlüssel nutzen möchte. Die Karten bieten diese Option an (deswegen habe ich sie auch ausgewählt). Leider kann der eingebaute Reader keine Extended-APDU, somit schlägt der Versuch fehl entsprechende Keys zu erzeugen (eigentlich sollte er die Keys erzeugen können aber es sieht danach aus dass die anschliessende Übertragung fehlschlägt:

tools> openpgp-tool -r 0 -v --verify CHV3 --pin 12345678 --gen-key 1 --key-len 3072
Connecting to card in reader Broadcom Corp Contacted SmartCard 0...
Using card driver OpenPGP card.
Fingerprint:
9DA81881C7139920120ABBF8C50BD95C 9A7C7684

tools> openpgp-tool -r 0 -v --verify CHV3 --pin 12345678 --gen-key 1 --key-len 4096
Connecting to card in reader Broadcom Corp Contacted SmartCard 0...
Using card driver OpenPGP card.
... multiple minutes later...
Failed to generate key. Error Transmit failed.

c:\Program Files (x86)\GNU\GnuPG> gpg2.exe --card-status
Application ID ...: D27600012401020100050000xxxx0000
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 0000xxxx
Name of cardholder: Bernd Eckenfels
Language prefs ...: en
Sex ..............: männlich
URL of public key : [nicht gesetzt]
Login data .......: [nicht gesetzt]
Signature PIN ....: nicht zwingend
Key attributes ...: 4096R 4096R 4096R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
...

Ach ja übrigens, noch ein paar Anmerkungen: Es ist wichtig gpg2.exe (nicht gpg.exe) zu verwenden, bei PGP4Win werden beide binaries in unterschiedlichen Versionen parallel installiert. Bei gpg2 muss man darauf achten dass es auf einige Hintergrundprozesse angewiesen ist (pinentry und scdaemon). Das kann schon mal zu Verwirrungen führen (z.b. Unter älteren Linux Varianten kann sich wohl ein Gnome daemon als pgp-agent ausgeben und dann smartcard befehle abweisen. Mit gpg-connect-agent -v und dem Befehl SCD GETINFO version lässt sich prüfen welcher Agent verwendt wird. In meinem Setup hängt sich auch die GPA artenverwaltng auch, habe noch nicht herausgefunden woran dies liegt.

Mit der Verwendung eines externen USB Readers der Extended APDU unterstützt (Gemalto IDBridge Ct710) lässt sich der 4096bit Key erstellen und nutzen:

c:\Program Files\OpenSC Project\OpenSC\tools>opensc-tool -v -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             Broadcom Corp Contacted SmartCard 0
     failed: Card not present
1    Yes   PIN pad   Gemalto IDBridge CT7xx 0
     3b:da:18:ff:81:b1:fe:75:1f:03:00:31:c5:73:c0:01:40:00:90:00:0c CryptoStick v1.2 (OpenPGP v2.0)

c:> echo debug-all > C:\users\eckenfel\AppData\Roaming\GnuPG\scdaemon.conf
c:> echo log file c:/temp/scdaemon.log >> C:\users\eckenfel\AppData\Roaming\GnuPG\scdaemon.conf
c:> echo reader-port "Gemalto IDBridge CT7xx 0" >> C:\users\eckenfel\AppData\Roaming\GnuPG\scdaemon.conf

c:\Program Files (x86)\GNU\GnuPG> gpg2 --card-edit -v

Application ID ...: D27600012401020100050000xxxx0000
Version ..........: 2.1
...
gpg/card> admin
gpg/card> generate
Make off-card backup of encryption key? (Y/n) n

gpg: NOTE: keys are already stored on the card!

Replace existing keys? (y/N) y
What keysize do you want for the Signature key? (3072) 4096
The card will now be re-configured to generate a key of 4096 bits
What keysize do you want for the Encryption key? (3072) 4096
The card will now be re-configured to generate a key of 4096 bits
What keysize do you want for the Authentication key? (3072) 4096
The card will now be re-configured to generate a key of 4096 bits
...
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
gpg: writing self signature
gpg: RSA/SHA256 signature from: "CE551545 [?]"
gpg: writing key binding signature
gpg: RSA/SHA256 signature from: "CE551545 [?]"
gpg: writing key binding signature
gpg: RSA/SHA256 signature from: "CE551545 [?]"
gpg: writing key binding signature
gpg: RSA/SHA256 signature from: "CE551545 [?]"
gpg: writing key binding signature
gpg: RSA/SHA256 signature from: "CE551545 [?]"
gpg: writing public key to `C:/Users/eckenfel/AppData/Roaming/gnupg/pubring.gpg'
gpg: writing secret key stub to `C:/Users/eckenfel/AppData/Roaming/gnupg/secring.gpg'
gpg: using PGP trust model
gpg: key CE551545 marked as ultimately trusted
public and secret key created and signed.

pub   4096R/CE551545 2016-06-05 [expires: 2016-06-06]
      Key fingerprint = 1C93 E95E 0486 C55C 0762  3629 20CC CA05 CE55 1545
uid       [ultimate] Bernd Eckenfels (test) <test@test>
sub   4096R/F738D4AE 2016-06-05 [expires: 2016-06-06]
sub   4096R/309D4991 2016-06-05 [expires: 2016-06-06]

Das Erstellen von 3 Schlüsseln (inkl. Signaturen, ohne Encryption Key backup - d.h. auch auf der Karte erstellt) mit 4096 bit dauert (stark schwankend) 30 Minuten, die selbe Prozedur mit 3072 bit Schlüssel erfolgt in 8 Minuten.

Bei der Erstellung der Schlüssel gibt pgp2 wenige Zwischenschritte aus, man kann das ganze aber im scdaemon logfile nachvollziehen. Wie oben zu sehen war es auch notwendig den Klartext Namen des externen Card Readers zu konfigurieren, scdaemon hat reader-port 1 oder reader-port 32769 (trotz Neustart) schlichtweg ignoriert. Auch wenn der richtige Reader verwendet wird scheint die Debug Ausgabe nur den Slot des Readers aber nicht den gewählten Reader auszugeben:

scdaemon[14808] Handhabungsroutine f³r fd -1 gestartet
scdaemon[14808] detected reader `Broadcom Corp Contacted SmartCard 0'
scdaemon[14808] detected reader `Gemalto IDBridge CT7xx 0'
scdaemon[14808] detected reader `'
scdaemon[14808] reader slot 0: not connected

Bei der Key-Erstellung hat gnupg2 das externe Keypad des Gemalto readers für die PIN Eingabe (noch) nicht benutzt.

Falschfarben und hängende Eingabe bei Samsung Galaxy Tab 3 10.1 reparieren

Ich habe schon längere Zeit ein Samsung Galaxy Tab 3 10.1 (GT-P5200). Das Gerät ist den ganzen Tag im Einsatz. Nach einem etwas unfreiwilligen Sturz auf das Laminat zeigte das Tab nur noch sehr grob-pixelige Bilder in Falschfarben an. Das scheint ein relativ weit verbreitetes Problem bei den Geräten zu sein. Leider gab es in den diversen Foren keine wirkliche Hilfe (es ist jedenfalls nicht die "Inverted Screen" Android Funktion für erleichterte Bedienung). Meine Hoffnung war eine lockere Steckverbindung, und so habe ich mich dran gemacht das Gerät selbst zu inspizieren.

Zuerst habe ich ein Youtube Video gefunden bei dem beschrieben wird, wie man den Akku in dem Tab austauscht. Das war sehr hilfreich, dort kann man nämlich erkennen wie man das Gehäuse öffnet. Entgegen meiner ersten Annahme hebelt man es von der Vorderseite aus auf. Leider habe ich nicht das gezeigte Plastikwerkzeug, aber mit einem Messer oder flachen Schraubendreher ist es recht einfach den Rand nach außen zu heben und das Innenleben anzuheben. Im Wesentlichen muss man nur darauf achten nicht zu tief einzustechen.

Nach dem Öffnen sieht man auch gleich drei Flachbandkabel. Zwei davon sind für Display und Digitizer zuständig, das dritte führt zu der USB Buchse. Auf dem linken braunen Kabel befindet sich die Bezeichnung MCF-101* - dies ist das Kabel für den Touch Digitizer. Das ist besonders empfindlich da es mehrere Stiftreihen hat. Das rechte schwarze Kabel (ST1_LCD*) ist für die Anzeige.

Wie im Video gezeigt (TC 4:45:00) muss man zuerst die Klebestreifen ablösen, dann einen kleinen Bügel anheben und kann dann die Kabel herausziehen oder wieder ordentlich einstecken. Hat das Display Kabel Kontatprobleme kommt es zu Anzeigefehlern, beim Digitizer reagieren einzelne Bereiche nicht auf Touch oder die Auswahl springt.


Tab InnenlebenIch hatte mehrere Versuche benötigt weil ich zunächst das falsche Kabel gelöst hatte. Am Ende war es dann aber recht einfach. Beide Kabel habe ich mit neuen Klebestreifen fixiert. Ich würde empfehlen das Gerät vor dem Verkleben oder Zusammenbau auszuprobieren (dabei nie auf die Elektronik fassen).

Meine Vermutung ist dass eine Erschütterung des Gerätes sich auf die Kabel auswirkt weil diese über den schweren Akku verlaufen, dort teilweise sogar festgeklebt sind. Ich habe entsprechend vermieden die Kabel mit dem Akku zu verkleben.

Dell BIOS Upgrades (Latitude E6510)

Ich wollte meinem etwas älteren Dell Latitude E6510 ein BIOS update gönnen, in der Hoffnung ein paar der Probleme die ich mit dem Akku und dem thermischen Verhalten habe damit etwas in den Griff zu bekommen. Dank dem Service Tags konnte ich auf der Support Seite auch schnell die benötigten Downloads ausmachen. Mein Gerät hatte ein BIOS in der Version A06, auf der Webseite stand als letzte Version die A16 bereit.

ScreenshotDie BIOS Updates bei Dell kommen als Bundle mit Flashes für das Bios, das System Management, die Intel Management Engine und weiterer Komponenten. Wenn man das Programm startet so frägt es nach dem BIOS Passwort, und nach wenigen Sekunden wird der Rechner auch für den Update Rebootet. In meinem Fall geschah allerdings nach dem Reboot nichts weiter. Das System meldete die gleiche alte Version weiterhin. Keine Fehlermeldung. Ich hatte dann mit verschiedenen Optionen herumgespielt, z.B. den Upgrader als Administrator zu starten, oder im abgesicherten Modus meines Win7 x64. Aber alles hat nicht weitergeholfen.

Nach ein wenig herumsuchen auf den Support Webseiten habe ich festgestellt dass bei ein paar der älteren BIOS Versionen eine Mindestversionsnummer vorausgesetzt und auch abgeprüft wird. Ebenso gibt es die Empfehlung mit der BIOS Version zu beginnen die das System schon hat. Und tatsächlich haben sich einige der dazwischenliegenden Versionen auch geweigert eine ältere A06 zu aktualisieren. A06-A08 konnte ich allerdings gar nicht installieren, da der Upgrader statt zu rebooten gecrashed ist. Übrigens werden nicht alle älteren Versionen in der Rechner-spezifischen Supportseite angezeigt, die Volltext Suche jedoch findet die Downloads in allen benötigten Versionen.

Screenshot: USB BootIch habe dann gesehen, dass die Updater .exe Files nicht nur mit Windows benutzt werden können, sondern auch mit DOS. Und das war dann die Lösung: alle BIOS Versionen auf einen USB Stick kopiert auf dem SystemRescueCd (mit LinuxLiveUSB) installiert ist. Dieses bringt auch FreeDOS (für diverse DOS Firmware Utilities) mit. Davon gebootet zeigte die BIOS Update Routinen sich sehr leicht bedienbar, und vor allem erfolgreich beim Update. Zuerst von A06 auf A06 - das hat dazu geführt dass der nächste Update auf A07 schon besser die Versionen der einzelnen Systemkomponenten anzeigen konnte. Und vor allem fand nach dem Reboot auch ein Flash Vorgang statt, der vorher nicht zu sehen war.

Screenshot: BIOS Update unter DOsMeine Vermutung: ältere BIOS Updater können zwar noch richtig prüfen ob man auf einer erforderlichen Minimalversion ist, dafür stürzen diese aber unter aktuellem Windows 7 x64 ab. Neuere Updater (insbesondere A16) funktionieren zwar problemlos mit Windows 7, prüfen aber die Minimalvoraussetzung nicht. Nach dem Reboot wenn das BIOS geflashed werden soll, wird die Version geprüft und der Update verweigert - jedoch ohne sichtbare Fehlermeldung.

Es ist schade, dass Dell hier ein sehr uneinheitliches Erlebnis hat: die BIOS Updater sind einfach zu bedienen, arbeiten schnell und sind durch die Unterstützung von Windows und DOS sehr flexibel. Gleichzeitig erwartet anscheinend keiner bei DELL, dass man nicht alle 6 Monate ein neues BIOS einspielt, entsprechend lückenhaft ist die QA bei so einem Update Schritt. Dass es ärgerlich ist, dass ich 5 Zwischenversionen einspielen musste: geschenkt.

 

Übrigens bietet Dell in der Knowledgebase einen Artikel an, welche BIOS Versionen welche Mindestvoraussetzungen haben. Es steht nicht dabei dass es auch für Folgeversionen gilt, aber meine Erfahrung ist jetzt, man muss alle Zwischenschritte gehen:

Article ID: 603480 (2013-05-07): Dell Optiplex, Latitude and Precision BIOS Dependency Chart

Product Installed Must Update Before Version
Latitude E6510 A08 A09 A10
Latitude E6510 A10 A11 A12

Meine Reihenfolge: A06 -> A06 -> A07 -> A09 -> A10 -> A11 -> A16.

Eines der neuen Features der Firmware ist die (nicht wieder abschaltbare) Option nur BIOS Updates mit gültiger Dell Signatur zu erlauben. Das ist angesichts der Einfachheit mit der man den BIOS Update anstoßen kann sicherlich sehr empfehlenswert, allerdings scheue ich nach meinen Erfahrungen mit der schlampigen QA bei Dell doch etwas davor zurück.

Eckpunktepapier der BNetzA zu Smart Grids und Markets

Die Bundesnetzagentur hat ein Eckpunktepapier zum Thema Smart Grids und Markets veröffentlicht. Damit will die Bundesbehörde
durch dieses Papier eine intensivere Diskussion der Thematik anstoßen zu können und die Veränderungen des Energieversorgungssystems weiter voran zu bringen. Dieses Eckpunktepapier soll die Diskussion zu dieser Thematik weiter befördern und besser strukturieren.
Das "Eckpunktepapier der Bundesnetzagentur zu den Aspekten des sich verändernden Energieversorgungssystems" enthält Leitgedanken und Begriffsdefinitionen und ist schon aus diesem Grund sehr lesenswert. Ob die einzelnen Thesen (Abnahme des Gesamtenergieverbrauchs) nun zutreffen wird sich zeigen, von einer Zunahme der Stromabnahme wird aber ausgegangen. Auch bei intelligenteren Verbrauchern (da zunehmend andere Energieformen verdrängt werden, was angesichts der Endlichkeit von fossilen Energieträgern nur logisch ist). Das Paper baut darauf, dass Verbraucher sich über Marktsignale (Preise) steuern lassen. Das wird sich zeigen wie gut das funktioniert... Ein wenig sehr optimistisch dürfte die Annahme der Transaktionskostensenkung bei "kleinteiliger Interaktion" sein (Fehlschläge im Smartmeter Markt wie in den Niederlanden oder Großbritannien deuten ja eher darauf hin, dass es sinnvoll sein kann alternative Lösungswege anzustreben und nicht alles über Informationstechnologie lösen zu wollen. Größtenteils wird der Smartmetermarkt von Anbietern getrieben die sich neue Einnahmequellen versprechen und die Vorteile werden in den meisten Haushalten weder gesehen - noch existieren diese). Das BNetzA Papier sieht dies aber auch (Leitgedanke 4). Was mir persönlich im Papier fehlt ist ein klarere Fokus auf das Thema Datenschutz, Schutz von kritischen Infrastrukturen und Monokultur. Die Notwendigkeit von Datendrehscheiben wird nicht hinterfragt, und eine Vermischung der Messdaten von Prosumenten oder Industrieabnehmern mit den Messstellen in Haushalten führt meiner Meinung nach zu einer Übertechnisierung der Haushalte. Für eine zuverlässige Demand-Site Prognose ist meiner Meinung nach nicht notwendig den Tagesverlauf jedes einzelnen Haushaltes zu betrachten - ganz im Gegenteil das ist eher schädlich. Der Nutzen von mehr Transparenz beim Stromverbrauch eines einzelnen Haushaltes kann auch durch eine rein lokale Informationsanwendung (deutlich besser) gelöst werden. Eine feingranulare Übermittlung von Messwerten erscheint mir nicht zwingend notwendig und vor allem nicht Ökonomisch. In dem Zusammenhang verweise ich auch auf den Artikel in der aktuellen Datenschleuder #95 (Power to the People, Das Stromnetz der Zukunft, Mathias Dalheimer, Seite 35-48) und die Projekte mySmartGrid sowie volkszaehler.org.

Hardware Security

Kris weißt in einem Tweet auf eine Diskussion zum Thema Sicherheit von Management-Adaptern hin. Im konkreten Fall wurde vermutet dass ein BMC (Der Mikro-Controller der die IPMI Schnittstelle bereitstellt) Spam Mails versendet hatte (nachdem er kompromittiert wurde). In dem Forum wird nicht klar, ob es wirklich der Fall ist und welche Schwachstelle dabei verwendet wurde. Aber in den Kommentaren sind einige sehr bedenkliche Meinungen und Vorgehensweisen zu entdecken: Management Adressen (SSH, HTTP, Remote-IPMI) werden von einzelnen Admins absichtlich im öffentlichen Netz zugänglich betrieben - oder aus Versehen aus Unkenntnis. Hersteller der BMCs installieren keine oder unsichere Default-Passwörter. Generell waren die Admins der Meinung dass BMCs gar nicht die Ressourcen haben um Spam zu versenden, und es wird unterstellt die Firmware auf den Controllern sei unbedingt sicher. Das ist natürlich eine naive Annahme. Auf den BMC Mikro-Controllern läuft ein Betriebssystem mit vollem IP-Stack und Anwendungsprozesse (Web Server, SSH Daemon, IPMI Agent, Shell/Menu) und diese können natürlich falsch konfiguriert werden oder verwundbar sein. Die IPMI Firmware wird oft von Administratoren vernachlässigt, weil es nicht in den normalen Update Prozessen des Betriebssystems integriert ist. Ich sehe folgende Punkte für den Betrieb von Servern mit Management Adaptern (oder Lights-Out Karten) als wichtig an:
  • Firmware des BMC in den Update/Patch Prozess aufnehmen
  • Mittels physischer Ports oder VLANs BMC in getrenntem Management LAN betreiben
  • Zugriff auf Management LAN beschränken, nur über sichere Hops zugreifen lassen
  • Server provisioning Prozedur muss sichere Konfiguration der BMC Adapter beinhalten (Zertifikate, Passwörter, User, evtl. SSO, WoL Secret....)
  • Verzicht auf Produkte die keine Netzwerksicherheit (Verschlüsselung) bieten
Generell kann man sagen, der Remote-Zugriff auf BMC Funktionen ist vergleichbar mit physikalischem Konsolen-Access (besonders dann wenn hier auch Consolas und Laufwerke gemapped werden können).

WLAN to go (Trekstor Portable WLAN HotSpot)

Vor einiger Zeit habe ich mich bei der PR Agentur von Trekstor beschwert, dass diese mir als Blogger zwar unverlangt Pressemitteilungen senden, aber ohne Testgeräte ich nicht viel berichten kann und will. Jetzt habe ich überraschend ein Testgerät von Trekstor erhalten, und will dies hier gerne besprechen: In einem sehr kleinen Paket habe ich den "Trekstor Portable WLAN Hotspot" für einen 2-wöchigen Test erhalten. Ein Gerät in der Größe eines Mobiltelefons das als WLAN Hotspot eingesetzt werden kann, und dabei die Verbindung mit dem Internet mittels eingebauter UMTS Funktion herstellt. Es ist also ein UMTS WLAN Router, benötigt dabei aber keinen externen USB Stick, die SIM-Karte des Mobilfunkanbieters wird direkt in das UMTS fähige Gerät eingelegt. Bis zu 5 WLAN Geräte können sich mit dem Hotspot verbinden, und dieser stellt dann die Verbindung zum Internet via UMTS/HDSPA (3G) oder GSM her. Zusätzlich hat das Gerät einen Mini-USB Anschluss über das es geladen werden kann. Über diesen USB 2.0 Anschluss kann auch ein weitere Rechner (Via Hi-Speed USB 2.0 Netzwerk Interface Treiber) angebunden werden. Der kleine Hotspot kümmert sich dabei um NAT, Firewall, hat einen DNS Proxy und DHCP Server eingebaut. Konfiguriert wird das Gerät über den Web Browser. Die Knöpfe am Gerät beschränken sich auf ein Minimum (Ausschalter, WLAN Schalter, Manueller Connect). Das Trekstor Gerätes ist Baugleich mit dem E5 von Huawei (dies wird auch nicht versteckt, das Logo ist auf der Rückseite zu sehen). Das Gerät ist Netlock frei, konnte in meinem Test mit Prepaid Standard SIM Karten von blau.de ebenso wie mit einem UMTS Datenvertrag von O2 genutzt werden. Es unterstützt UMTS im 2100MHz Band sowie Quad-Band GSM (EDGE, GPRS) 850/900/1800/1900MHz - ist also für Reisen geeignet. Das WLAN Modul kann im 2,4GHz Band die Kanäle 1-13 nutzen. (Es gibt bei den Europäischen Modellen eine Ortseinstellung bei der man auch "Japan" auswählen kann, diese schaltet aber keinen weiteren Kanal frei). Das Gerät unterstütz WPS, konnte ich aber mangels Gegenstelle nicht testen. Diese Funktion klingt aber kaum einfacher als das abtippen eines Passwortes von der Gehäuserückseite.
Die Anwendungsfälle sind vielfältig. Als Besitzer von Internet Tablets oder Game Consolen die keine UMTS-Stick Möglichkeit haben ist das Gerät auf jeden Fall eine praktische Option. Weiterhin kann das Gerät von kleinen Reisegruppen oder Arbeitsgruppen mit Note- oder Netbooks genutzt werden um einen (teuren) Internetzugang gemeinsam zu benutzen. Es ist damit Ideal geeignet die Wartezeit am Flughafen zu überbrücken ohne dass jeder der beteiligten einen eigenen Datentarif haben muss (einige Provider erlauben nicht den Betrieb von mehreren Geräten per NAT, dies muss im Einzelfall geprüft werden). Praktisch an dem Prinzip der WLAN Anbindung ist, dass in der Regel alle Geräte ohne spezielle Treiber die Vermittlungsfunktion des Gerätes nutzen können. Es wird dabei WLAN nach 802.11 b/g mit WPA und oder WPA2. Der WLAN Hotspot wird mit einem austauschbaren 3.7 V, 1500 mAh Akku geliefert. Es kann über USB vom Rechner geladen und mit Strom versorgt werden. Bei meinen Tests hatte es Laufzeiten von über 4h. Es kann dabei auch von USB Steckernetzteilen oder externen Akkus (Test mit einem Phillips Reserveakku, der zum Beispiel von iPhones nicht akzeptiert wird, war erfolgreich). Als zusätzliche Funktion bietet das Gerät übrigens noch einen MicroSD Kartenslot in der Speicherkarten bis zu 32GB eingesteckt werden können. Diese können dann entweder über den USB Anschluss benutzt werden, oder der Zugriff auf den Inhalt steht über den Web Server des Geräts zur Verfügung. Generell ist das Gerät und die Software gut durchdacht, es können mehrere Mobilfunk Profile angelegt werden; mutige Zeitgenossen können die Mobilfunk-PIN im Gerät speichern; wenn Roaming erkannt wird vermeidet das Gerät automatisch Online zu gehen. Bei der Auslieferung hat das Gerät einen eindeutigen Verschlüsselungskey (der auf der Geräterückseite aufgedruckt ist). Die NAT (ALG, DMZ) und Firewall Funktionen können mit guten Home Routern locker mithalten. Das Gerät wird mit einem kurzen Mini-USB nach USB Kabel geliefert (aber keinem Netzteil) und einem Quick-Start Guide der keine der Optionen der Software auch nur ansatzweise erklärt. Er ist aber ausreichend um die erste WLAN Verbindung mit dem Gerät aufzubauen (Ich empfehle als einer der ersten Aktionen den WPA2 Modus zu aktivieren). Ja, ich kann das Gerät fast nur loben, auf der Seite der Nachteile sehe ich vor allem den relativ hohen Preis (wobei es im direkten Vergleich mit anderen Geräten in der Leistungsklasse mit 139,- Eur günstig abschneidet), kleinere Lieblosigkeiten in der recht technischen Web Oberfläche (zum Beispiel die Deutsche Übersetzung "x Tag x Stunden x Protokoll") und die doch recht knappe Begrenzung auf 5 WLAN Clients. Das OLED Dot Display ist recht übersichtlich aber unter vielen Lichtbedingungen kaum abzulesen (spiegelt). Dem Gerät fehlt auch eine VPN Funktion, allerdings sehe ich das nicht als Nachteil an, ein VPN sollte besonders in diesem Einsatzszenario (WLAN) auf dem Endgerät (Notebook) terminiert werden. Für den stationären Einsatz würde ich das Gerät nicht empfehlen, ebenfalls nicht zur (Not)Versorgung von Veranstaltungen mit Internet (wegen der Anzahl der Clients und den fehlenden externen WLAN Antennen). Aber als Reisebegleiter macht es eine sehr gute Figur. Ich habe keine Erfahrungen mit der Stabilität des Gehäuses, beim Anfassen traut man dem Gerät keine große Robustheit zu. Das Gerät ist auf jeden Fall im Vergleich zum Mitbewerb (D-Link MyPocket, Novalink MiFi) sehr kompakt.

Ticker auf dem iPhone

Für mich ist das iPhone ein praktischer Begleiter, der oft den Blick auf den Notebook erspart. Ich wechsle öfters zwischen dem Twitter Client, der Xing Status Meldung, Mails, diversen Web Seiten und Feeds hin und her. Um das etwas zu verbessern habe ich nach einem Ticker gesucht. Zwar hat das iPhone OS noch nicht den Event-Push Dienst, den Apple für 3.0 angekündigt hat, aber es gibt im Cydia Repository ein nettes Winterboard Widget mit Namen iTicker. Dieses zeigt auf der Springboard Menu Seite RSS Einträge an. Das ganze ist eine HTML Seite mit etwas CSS und JavaScript kann man also gut seinen Bedürfnissen anpassen. Ich habe es so erweitert, dass es 2 Einträge pro Seite anzeigt und das Author Feld farblich abgesetzt voranstellt. Da stellt sich jetzt nur die Frage, welchen Feed ich hier anzeigen will. Es gibt einige Diente die Meldungen bereitstellen die für mich relevant sind. Manche Dinge sind dabei wichtiger und sollen nicht im endlosen Updates-Strom untergehen. Manche Meldungen erhalte ich über mehrere Feeds. Aber es gibt ja zum Glück Yahoo Pipes. Hier kann ich mehrere RSS Feeds aggregieren, filtern und nachbearbeiten. Zum Beispiel nehme ich mindestens das letzte Tweet meiner Frau (wenn dies nicht älter als einen Tag ist) und einige Tweets aus dem Facebook Friends News Feed. Das kopiere ich alles zusammen, entferne Duplikate anhand vom Link und schneide den Namen aus dem Titel ab und stecke Ihn (falls nicht schon vorhanden) in das Author Feld. Im iTicker habe ich die Pipe fest hinterlegt, kann deren Inhalt aber jederzeit grafisch zusammenstellen. Bei dem ganzen Unterfangen hat es mir geholfen dass ich die iTicker Dateien einfach auf dem Windows Rechner bearbeitet habe. Diese sind in Firefox lauffähig, und dank Firebug Extension war das JavaScript und CSS Debugging auch recht einfach. Um auf dem iPhone Änderungen zu machen habe ich die Dateien per SSH und vi geändert, anschliessend hilft mir die SBSettings Erweiterung das Springboard schnell neu zu starten ("Respring"). Jetzt muss ich nur noch herausfinden wie ich die Updates des Feeds besser kontrollieren kann. Irgendwie scheint da noch eine Google JS Feeds Library nicht ganz mitzuspielen.

Java Concurrency Termine

Gleich zwei Termine zum Thema Java Concurrency stehen in der Region an: Java User Group Karlsruhe - "The Secrets of Concurrency" Mittwoch, 2009-02-11 19:15 Uhr Dr Heinz Kabutz (PhD CompSci) Author des The Java(tm) Specialists' Newsletter Ort: Uni Karlsruhe, ATIS, Am Fasanengarten 5, Geb. 50.34, 76131 Karlsruhe, Raum UG102 und ObjektForum Stuttgart - Herausforderung Multikern-Systeme Montag, 2009-02-16, 18.30 Uhr Prof. Dr. Walter F. Tichy Universität Karlsruhe / FZI Ort: Alte Scheuer, Degerloch