Auf den Versuch, Entrust IdentityGuard Mobile auf (m)einen Google Pixel mit aktuellem LineageOS 16 in Betrieb zu nehmen, hat die App nur mit einem

Manuelle Aktivierung wird auf einem ungesicherten Gerät nicht unterstützt

reagiert. Tatsächlich fördert die Suche auf der Entrust-Website die Info hervor, daß der Betrieb der App auf einem Custom Rom nicht möglich ist.

Entrust IdentityGuard mobile has detected that it is running on an unsecured device. Application exiting

The issue is that you have Jail broken (iPhone) Rooted (Android) or hacked/cracked your mobile device, you will not be able to install the soft token and will need to either install it on a different device (e.g. workstation or other mobile device) or switch to the eGrid Card.

Stattdessen läuft die App jetzt auf einem Nexus 4 unter Android 5.1.1mit Softwarestand Juli 2015, bestimmt ein riesiger Sicherheitsgewinn.

Im August 2016 im Ausfverkauf erworben, hat sich mein Nexus 5X vorletzte Woche nach rund 2 1/2 Jahren außerplanmäßig verabschiedet. Auch bei mir hat der berüchtigte Mainboard-Fehler zugeschlagen, der wie ein Damoklesschwert über jedem der Geräte schwebt. Mitten während einer Photoaufnahme ist das Bild eingefroren, das Display wurde schwarz und das Telefon reagiert seither nicht mehr.

Wie bei den meisten von Murphy sorgfältig geplanten Aktionen ist dies natürlich nicht kurz nach der mehr oder minder regelmäßig durchgeführten Datensicherung am heimischen PC passiert, sondern mitten im Urlaub. Der Verlust des Telefons und der damit verbundenen Kommunikationsmöglichkeiten war ärgerlich aber nicht weiter tragisch - deutlich schwerer wiegt der Verlust von rund 200 Photos, welche im Laufe des Urlaubs gemacht wurden und noch im internen Speicher des Telefons liegen.

Es gibt zwar verschiedene Methoden, mit denen das Telefon mit Glück kurz zum Leben erweckt werden kann, aber bis zur Datenrettung hat leider keine geführt. Zwar konnte mit Hilfe der Kühlmethode das Telefon nochmal bis in den Fastboot-Modus gestartet werden, aber schon das installierte TWRP-Revovery war bereits nicht mehr erfolgreich zu starten. Mit Hilfe eines modifizierten Bootimages, das die Anzahl der benutzten Prozessorkerne reduziert, gelang einmalig der Start im Recovery-Modus - aber auch hier erfolgte nach wenigen Sekunden ein Neustart.

Es ist gut und lobenswert, wenn sich Medien, die sich normalerweise mit einem breiten Spektrum an Themen beschäftigen (und somit auch eine breite Leserschaft haben) auch Technik-Themen in ihre Veröffentlichungen aufnehmen - so kann auch unter einer vielleicht nicht unbedingt technikaffinen Leserschaft die Aufmerksamkeit auf bestimmte Themen gelenkt werden.

Dies hat Spiegel Online mit dem Artikel "Vorsicht, Schnäppchenhandy" probiert und sich dabei zielsicher eines der denkbar schlechtesten Beispiele ausgesucht: das HTC Tablet Nexus 9.

Der Einleitungstext erklärt:

Elektromärkte werben mit Sonderpreisen für Handys und Tablets. Was sie verschweigen: Viele Geräte sind Hackerangriffen schutzlos ausgeliefert. Was hilft?

und begründet das Beispiel mit

Ab November stellt Google gar keine Sicherheitsupdates mehr für das Gerät zur Verfügung. ... Versionsupdates des Betriebssystems Android gibt es für das Modell schon seit Oktober 2016 nicht mehr.

Die (eigentlich nicht vorhandene) Update-Politik vieler Hersteller ist ein Graus: solange es sich nicht gerade um Top-Modelle handelt, bekommen viele Geräte so gut wie nie ein Update oder wenn, dann nur extrem unregelmäig.

Dabei sind die oben angesprochenen Versionsupdates zwar für das Marketing gut und wichtig, für die eigentlich im Spiegel-Online-Artikel angesprochenen Sicherheitsprobleme sind Sicherheitsupdates deutlich relevanter. Dies ist analog zu z.B. Windows-PCs, wo die aktuelle Betriebssystemversion bereits seit über einem Jahr "Windows 10" heißt, das noch vielfach eingesetzte Windows 7 aber trotzdem noch bis 2020 mit Sicherheitsupdates versorgt wird.

Genau an dieser Stelle ist das von HTC hergestellte und von Google mit naktem Android ausgestattete Nexus 9 als schlechtes Beispiel nur bedingt geeignet, denn für das Tablet sind zum Zeitpunkt des Artikels (29. Oktober 2017) die aktuellsten, für Android erhältlichen Sicherheitsupdates (Patchlevel 05. Oktober 2017) verfügbar.

Vergleicht man das mit einem ebenfalls im Haushalt vorhandenen Samsung Galaxy Tab A T580 stellt man fest, daß dieses aktuelle Tablet auf dem Patch-Stand "1. August 2017" ist, also dem aktuellen Stand zwei Monate hinterherhinkt.

Dies soll nicht heißen, daß es heute noch sinnvoll wäre, ein neues Nexus 9 zu kaufen, denn das Supportende ist entweder nah oder da, aber mit dem aktuellen Patch-Stand ist das Nexus 9 zumindest besser aufgestellt, als ein Großteil der als brandneu verkauften Geräte, bei denen ungewiss ist und bleibt, ob und wann sie eventuell ein Update erhalten.

Für die Besitzer eines Nexus 9 bleibt, sollte ab nächstem Monat tatsächlich kein Sicherheitsupdate mehr erscheinen, ein Ausweg: der Umstieg auf ein Custom Rom wie z.B. Lineage OS, mit dem auch ein inzwischen zwei Jahre aus der offiziellen Wartung gefallenens Nexus 4 mit Android 7.1.2 inklusive aktuellsten Sicherheitsupdates versorgt wird.

Mit Android 8 Oreo hält eine neue nervige Funktion in das Betriebssystem Einzug, die leider standardmäßig aktiviert ist und für deren Abschaltung man erstmal eine Odysee durch die Einstellungen machen muß:

Password in Formulare von Google ausfüllen lassen speichern?

Sobald das Betriebssystem auch nur annähernd den Eindruck hat, man möchte gerade ein Kennwort speichern, öffnet sich ein Popup mit der oben genannten Frage und den Optionen "Nein Danke" sowie "Speichern" und leider keiner Möglichkeit, die Funktion direkt zu deaktivieren.

Will man die Funktion abschalten, so führt die Suche in "Einstellungen" > "System" > "Sprachen & Eingabe" > "Erweitert" und nennt sich "AutoFill-Dienst", doch leider bietet ein Klick auf das "Einstellungen"-Zahnrad zwar die Möglichkeit, gespeicherte Daten einzusehen, aber keine Möglichkeit, den Dienst zu deaktivieren.

Dies geht über einen Klick direkt auf "AutoFill-Dienst", wo die Option "Keine" gewählt werden kann, womit auch das Zahnrad in den Einstellungen verschwindet und im Nachhinein die Dienstkonfiguration fast logisch erscheint.

Sollte es auf einem Android-Gerät zu Fehlern kommen, kann - wie bei vielen anderen Systemen auch - ein Blick in die Logdateien helfen. Dies kann entweder direkt auf dem Gerät - oder deutlich komfortabler und besser auswertbar auf einem mittels USB verbundenen PC geschehen.

Zum Auslesen bzw. Mitschreiben der Logdateien muss zuerst das USB-Debugging aktiviert werden: hierzu die Einstellungen öffnen und den i.d.R. letzten Punkt "Über das Tablet" öffnen. Hier ebenfalls wieder bis zum Ende scrollen und insgesamt sieben mal auf die Zeile "Build-Nummer" tippen. Sofern man ein halbwegs standardkonforme Android-Version installiert hat, sollte nun der Hinweis erscheinen, daß man ab sofort Entwickler ist. In den Einstellungen wird nun der zusätzliche Punkt "Entwickleroptionen" angeboten. Diese Einstellungen öffnen, aktivieren und unter dem Punkt "Debugging" den Punkt "USB-Debugging" aktivieren.

Nun das Gerät mit dem Rechner verbinden und das Logging mittels

adb logcat -v long > Name_der_Logdatei

starten. Bei der ersten Verbindung erscheint eine Autorisierungsabfrage, die bestätigt werden muss. Ab sofort werden alle Meldungen in die oben genannte Datei geschrieben. Bei Bedarf kann die Ausgabe noch angepasst werden, nähere Informationen hierzu befinden sich in der Android Developer Dokumentation.