Ein kurzer Kommentar zum Assassins Creed Unity Bug Debakel:
Fehler über Fehler, damit war die neueste Inkarnation der Assassins Creed Reihe in den Schlagzeilen.
Da fragt man sich doch, haben die denn gar nicht getestet? Doch, aber vermutlich nicht intensiv genug. Und das mit Sicherheit wieder aus den zwei gleichen Gründen, wie schon so oft. Geld und Zeit. Man hat sich nicht die Zeit gegönnt, das ganze wirklich reifen zu lassen, hat wieder mal zu früh in den Medien Termine genannt und wahrscheinlich war man auch nicht wirklich bereit, das Geld zu investieren um sauber und intensiv zu testen. Es ist halt leider so, dass ein komplexes System wie es die Spielwelt von Assassins Creed ist auch mit komplexen Problemen zu kämpfen hat.
Und da ist vermutlich den Entwicklern noch der geringste Vorwurf zu machen. Wahrscheinlich war denen schon im Vorfeld klar, was kommen würde. Aber da hat mal wieder das Management und das Marketing über die Technologie gesiegt. IT ist kein einfaches Geschäft, auch wenn die Excel und Powerpoint Fraktion das gerne hätte.
Aber was daraus resultiert, kann man jetzt erleben. Schlechte Presse und verärgerte Spieler. Und das ausgerechnet vor dem Weihnachtsgeschäft. Ein größeres Ei hätte man sich nicht legen können. Aber ich bin mir sicher, der nächste Smash Hit wird mit den gleichen Problemen kämpfen müssen. Weil man mehr auf die Auswertungen der Excel Fraktion hört als auf diejenigen, die das Produkt WIRKLICH entwickeln. Wenn BWL über IT siegt, kommt halt so was dabei raus.
Beim Recherchieren über neue Smartwatches bin ich auf eine Uhr gestossen, die man gut als einen der Vorläufer der Pebble Smartwatch bezeichnen könnte.
Genauer gesagt geht es um die TEXAS INSTRUMENTS – EZ430-CHRONOS-868 Uhr, die man unter anderem bei Farnell beziehen kann. Ja Moment, werden jetzt viele sagen, das ist doch eine Fitness-Uhr. Richtig, aber zum einen, die meisten aktuellen Smartwatches haben ebenfalls einen Fokus auf Fitnessfunktionen und zum anderen. Wenn man sich mal genauer mit dem Artikel befasst, stellt man schnell fest, dass diese Uhr sich bereits programmieren läßt. Und wenn man wiederum beobachtet, worüber bei den Smartwatches neben dem Darstellen von auf dem Smartphone eingegangenen Nachrichten meist berichtet wird, dann sind das die Fitnessfunktionen.
Die aktuellen Smartwatches unterscheidet von Uhren wie der EZ430 oder anderen Sportuhren meist, dass sie nur in Zusammenhang mit einem Smartphone funktionieren. Bzw. wenn sie alleine arbeiten, dann auf der Basis eines Smartphone Kerns, wie z.B. die Uhr von Pearl. Und natürlich das andere Display. Wobei man hier auch immer drüber nachdenken sollte, welche Anwendungen man nutzen möchte. Denn gerade bei Wearable Devices sollte man immer auch an das Anwendungsfeld denken. Die eierlegende Wollmilchsau wird mit Sicherheit, wenn überhaupt dann noch ein paar Jährchen auf sich warten lassen. Ich sehe in der Zukunft eher kleine, energiesparende und vor allem günstige Wearable Sensoren und Tracker, die zu bestimmten Zeiten mit dem Smartphone, Tablet oder PC synchronisiert werden.
Was ich hier aber eigentlich sehr spannend finde ist die offene Architektur der EZ430. Man kann die Uhr umprogrammieren, und hat somit eine Plattform, um jenseits bisheriger Anwendungen der Uhr auch noch andere Funktionen zu nutzen.
Natürlich lässt sich die Chronos nicht direkt mit der Pebble vergleichen, schon wegen des anderen Ansatzes und der anderen Zielgruppe. Aber was ich spannend finde ist die Tatsache, dass unabhängig von Smartphones bereits vor Jahren darüber nachgedacht wurde, verschiedenste Funktionalitäten am Handgelenk zu tragen. Und gerade für Hacker dürfte die doch ausgesprochen günstige Chronos inklusive Entwicklerkit (bei Farnell im Moment für 57,76 Euro zu haben) durchaus interessant sein.
Es gibt Dinge zu beachten, die nur für mobile Endgeräte gelten.
Android ist strukturiert wie ein Orchester mit vielen „Spielern“, verschiedensten Komponenten, die erst zur Laufzeit miteinander verknüpft durch die „Intents“ die Messengerkomponenten. Wie kann ich nun diese Komponenten absichern, wenn Intents schief laufen.
Es gibt das grobgranulare Sicherheitsmodell basierend auf der Sicherheit des Linux Kernels, der die Prozesse isoliert.
Desktop hat Single UID
Android hat UID per Application
Applikationen, die mit dem gleichen Schlüssel signiert sind, können mit der gleichen UID laufen.
Die Kommunikation zwischen Apps läuft über eine Binder IPC
Weiterer Schutz->Sandboxing von Applikationen
Ich kann nur meine eigenen Ressourcen ansprechen.
Jede App läuft in einer eigenen Instanz der Dalvik VM.
Kommunikation über spezielle Interfaces.
Weiterer Sicherheitsmechanismus
Signieren von Applikationen
Verantwortlich für die Signatur ist der Entwickler
Zertifizierung durch Entwickler und in Verantwortung des Entwicklers
Vertrauen in Entwickler durch Erstellung guter Anwendungen
Daneben Feingranulares Sicherheitskonzept
Basiert auf Permissions
Permissions schränken die Möglichkeiten ein, was Prozesse tun können.
Benutzer erkennt das an den angegebenen Rechten, die die App bei der Installation fordert.
Es gibt:
System permissions Erlaubnis auf Systemdienste zuzugreifen (z.B) Kalender oder Adressbuch
Custom permissions
Permission groups
Permission trees
Definiert werden die Permissions im Android Manifest.
Informationen über Apps und laufende Prozesse kann über PackageManager oder ActivityManager
PackageManager -> Installierte Programme
ActivityManager -> Laufende Programme
Wo sind die Verantwortlichkeiten des Entwicklers?
Per Default kann eine App vom „Umfeld“ nichts sehen.
Component wird exportiert durch android:exported im Intentsfilter
Intents sind vergleichbar mit Messengerobjekten
Niemals sensitive Daten in einen Intent
Ebenso von Anfang an angeben, wer den Intent sehen können soll.
Intentfilter filtern keine schädlichen Intents!
Ein Angreifer kann die Priorität seiner Intentfilter erhöhen.
Bei Intentfiltern spezifische Aktionen und Kategorien angeben und Datenfilter
Activities
Benuten von Activity android:permissions = „de.otw.android.HARM_USER_DATA“
Die Permissions werden in startActivity() bzw. startActivityforResult() geprüft.
Services
Client-> Intent.setComponent() um den Service eindeutig zu identifizieren.
Achtung bei der Verwendung von Binder Interface.
Genehmigung für ServiceConnection im Package Manager prüfen, vor dem Austausch sensitiver Daten.
Server: Genehmigung mit erzwingen
Feingranularere Zugriffskontrolle durch Verwendung von Binder und Context Hilfsfunktionen
Broadcast Receiver
Receiver: Wiederum eine Genehmigung erzwingen
Sender: Immer darüber nachdenken, wer den Intent empfangen können soll. Also einfordern einer Permission und Definieren des Empfängers des Intents.
Don’t user sticky broadcasts for sensitive data!
ContentProvider
Achtung, beim Verwenden eines ContentProvider intern, android:exported=“false“ explizit setzen.
Lese und Schreibrechte trennen
android:readPermission
android;writePermission
TAg schränkt zur Compiletime uri Zugriffe ein.
Mitkönne erlaubte Pfade für uri Zugriffe angegeben werden.
Tips:
Jegliche empfangene Daten aus einem Intent prüfen
SQL Statement und Daten die es enthält klar trennen.
Selection fields final machen um Kontaminierung aus Zufall zu vermeiden
Files, DB und geteilte Preferenzen könne mit Berechtigung installiert werden
Bei Zugriffsberechtigungen auf Datenbanken immer an die Konsequenzen denken und immer den User fragen.
Daten auf SD Karte NIE unverschlüsselt ablegen.
IMMER DRAN DENKEN Nutzerdaten SICHER speichern.
So wenig Permissions wie möglich, anstelle einer Permission manchmal besser ein Dialog.
Cookie-Zustimmung verwalten
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
