Julian Joswig: IT Blog

Zeige alle Artikel im Tag iOS

Zugriff auf managed und unmanaged Contacts in iOS 12 steuern

Geschrieben am 23. Sep 2018, 12:12

Apple hat mit der Freigabe von iOS 12 am 19. September 2018 wieder eine Reihe von Einstellungen in das Betriebssystem integriert, welche per Mobile Device Management (MDM) steuerbar sind und sich vorrangig an Unternehmensnutzer richtet. Wichtigste Neuerung ist die Steuerbarkeit des Zugriffes auf "managed" und "unmanaged Contacts" - eine Änderung, welche mit iOS 11.3 im Zuge der Inkraftsetzung der EU-DSGVO im März 2018 eingeführt wurde.

Hintergrund der Änderung

Die Unterscheidung zwischen "managed" und "unmanaged" bezog sich bis zur Freigabe mit iOS 12 im Wesentlichen auf Apps und Dokumente. Objekte konnten durch das Mobile Device Management System in eine der beiden Kategorien klassifiziert werden und der Datenaustausch zwischen beiden Welten limitiert werden. Beispielhaft konnte eine im Unternehmen genutzte App als "managed" klassifiziert werden und der Datenaustausch mit dem "unmanaged"-Bereich unterbunden werden. Im Ergebnis stand ein höheres Sicherheitsniveau, da es keine Vermischung zwischen privatem und beruflichen Bereich gab (der Spezialterminus für ein solches Konzept lautet DLP - Data Loss Prevention). Mit der Veröffentlichung von iOS 11.3 im März wurde diese Trennung zusätzlich auf die Kontakte des Geräts erweitert. Hintergrund war die Einführung der EU-DSGVO. Die Folgen waren aus Sicht der (privaten) Nutzer gravierend: auf im "managed"-Bereich gespeichert und synchronisierte berufliche Kontakte, welche beispielsweise auf einem Microsoft Exchange Server gespeichert sind, konnte im "unmanaged"-Bereich nicht mehr zugegriffen werden. Prominentes Beispiel: WhatsApp. Mit dem Ziel, das oben genannte Problem zu lösen, gab es nur zwei Ansätze:

  1. Es findet eines Deklaration von einer entsprechenden "unamanged"-App als "managed"-App statt
  2. Man lebt mit der Einschränkung

Offensichtlich waren die beiden oben genannten Lösungsalternativen nicht ausreichend, weshalb es nun neue Möglichkeiten gibt.

Neue Konfigurationsoptionen "allowManagedToWrite UnmanagedContacts" und "allowUnmanagedToRead ManagedContacts"

Mit der Veröffentlichung von iOS 12 werden nun neue Konfigurationsoptionen aufgenommen, welche den Zugriff granularer steuern lassen.

allowManagedToWriteUnmanagedContacts
Optional. If set to true, managed apps can write contacts to unmanaged contacts accounts. Defaults to false.
if allowOpenFromManagedToUnmanaged is true, this restriction has no effect.
A payload that sets this to true must be installed via MDM.
Availability: Available only in iOS 12.0 and later.
allowUnmanagedToReadManagedContacts
Optional. If set to true, unmanaged apps can read from managed contacts accounts. Defaults to false. if allowOpenFromManagedToUnmanaged is true, this restriction has no effect.
A payload that sets this to true must be installed via MDM.
Availability: Available only in iOS 12.0 and later.

Quelle: https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf Die Einstellung kann mit einem kompatiblen Mobile Device Management System auf die Geräte ausgerollt werden.

Vorteile der neuen Lösung

Es bietet sich somit nun die Möglichkeit, den Datenaustausch und Zugriff auf Kontakte zwischen "managed" und "unmanaged" etwas feingliedriger zu steuern. Gemäß dem obigen Beispiel wäre es also möglich, den Zugriff auf "managed"-Kontakte für "unmanaged"-Apps freizugeben und somit privat genutzten Apps, wie etwa WhatsApp, die Berechtigung einzuräumen. Ob das dauerhaft im Einklang mit der EU-DSGVO ist, muss an anderer Stelle separat evaluiert werden.


VPN-Server für iOS oder macOS selbst betreiben

Geschrieben am 26. May 2018, 15:32

Es gibt Situationen, in denen hätte man gerne einen VPN-Server zur Verfügung, um Datenverkehr in einer unsicheren Umgebung transportieren zu können. Das kann beispielsweise an Hotspots in Hotels, am Flughafen oder Bahnhof sein, da diese in aller Regel aus Gründen der Praktikabilität nicht verschlüsselt sind. Nutzt man dann unverschlüsselte Dienste, bspw. wird eine Webseite ohne HTTPS (TLS-Verschlüsselung) aufgerufen, kann diese Information mit einfachen Mitteln durch alle Nutzer des Hotspots abgegriffen werden. Die Lösung ist hier die Nutzung eines VPN-Servers (Tunnels), um die sensiblen Daten dort hindurch über das unsichere Netz zu übertragen. Es gibt eine Reihe von kostenpflichtigen VPN-Diensten, welche VPN-Tunnel für solche Zwecke bereitstellen. Manchmal jedoch leider mit Volumenbeschränkung. Sofern man einen öffentlich verfügbaren Server im Internet hat, bspw. aus der Cloud, kann man einen VPN-Server mit relativ einfachen Mitteln selbst betreiben und dann mit iOS (iPhone, iPad) oder macOS nutzen.

Voraussetzungen

Um ein solches Setup realisieren zu können, benötigt man mindestens folgende Dinge:

  • einen verfügbaren Server mit Linux (bspw. aus der Cloud von Amazon oder im heimischen Netz mit einem Raspberry PI) mit Ubuntu, Debian oder CentOS
  • Server muss zwingend per IPv4 erreichbar sein (IPv6 ist aus technischen Gründen nicht kompatibel). Dies sollte idealerweise eine feste IPv4-Adresse, kann jedoch auch eine dynamische Adresse sind.
  • ein kompatibles iOS (iPhone, iPad) oder macOS Gerät sein

Sollte man sich dazu entscheiden, einen Server beispielsweise im heimischen Netz zu betreiben (z. B. mittels Raspberry PI), so verfügt man in aller Regel nur über eine dynamische IP-Adresse. Um trotzdem eine stabile Erreichbarkeit des VPN-Servers über die dynamische IP-Adresse zu gewährleisten, sollte man einen "Dyndns"-Dienst verwenden.

Funktionsweise

Auf dem verfügbaren Server wird ein VPN-Server installiert, welcher einen Tunnel bereitstellt auf Basis von IPSec (IPSec/L2TP oder Cisco IPSec). Diese Art der Transportverschlüsselung gilt nach heutigen Maßstäben als sicher und ungebrochen. Das Endgerät (iOS oder macOS) baut eine Tunnelverbindung zum Server auf und schickt sämtliche Daten durch den verschlüsselten Tunnel. Selbst bei Nutzung von unverschlüsselten Diensten bleiben die Daten zumindest im unsicheren Hotspot-Netzwerk vor den Augen anderer Teilnehmer verborgen.

Installation

Eine aufwändige Installation ist lediglich für den Server durchzuführen. Für die Installation des VPN-Servers sei auf folgende Seite verwiesen: https://github.com/hwdsl2/setup-ipsec-vpn#installation iOS und macOS bringen im Standard schon die notwendige Software mit, um einen VPN-Tunnel zu unserem installierten VPN-Server aufbauen zu können. Es muss lediglich noch das iOS oder macOS Gerät konfiguriert werden:

Nutzung

Nach Einrichtung des Servers und iOS oder macOS Geräts kann eine VPN-Verbindung quasi per "Fingerschnipp" aufgebaut werden. Von diesem Moment an läuft jegliche Kommunikation vom Endgerät verschlüsselt über den VPN-Server in das Internet. Die Daten im unsicheren Hotspot-Netzwerk sind damit vor dem Einblick fremder geschützt. Ich selbst nutze diese Kombination in Verbindung mit einem Ubuntu Server, welcher bei einem deutschen Cloud Anbieter steht. Alle meine Endgeräte (iPhone, iPad, MacBook Air) können eine VPN-Verbindung zum Server aufbauen und ich damit sämtliche Verbindungen verschlüsseln.

Quellen:


iOS Updates auf Supervised Geräten mit iOS 11.3 verzögern

Geschrieben am 25. Jan 2018, 20:16

Wie mit allen iOS x.3 (d. h. 9.3, 10.3) Updates adressiert Apple vor allem Unternehmensnutzer. Auch diesmal hat Apple an Unternehmen gedacht und bringt eine Option, die in einigen IT-Abteilungen für Erleichterung sorgen wird: Auf Geräten mit iOS 11.3 können Systemupdates bis zu 90 Tage verzögert werden. Die Veröffentlichung von iOS 11.3 wird noch im Frühjahr 2018 erwartet.

Neue Konfigurationsoption "enforcedSoftwareUpdateDelay"

Mit der Veröffentlichung von iOS 11.3 wird eine neue Konfigurationsoption aufgenommen, welche die Option auf ein neues Release von iOS zu aktualisieren, bis zu 90 Tage lang unterdrückt. Die neue Konfigurationsoption lautet: enforcedSoftwareUpdateDelay. Zugeordnet ist diese Option den "Restrictions" in iOS. Als Beschreibung gibt Apple an:

Supervised only. This restriction allows the admin to set how many days a software update on the device will be delayed. With this restriction in place, the user will not see a software update until the specified number of days after the software update release date.
The max is 90 days and the default value is 30.
Availability: Available only in iOS 11.3 and later and macOS 10.13.4 and later.

Quelle: https://developer.apple.com/library/content/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html Es ist also möglich, auf Supervised Geräten (egal ob per Device Enrollment Program oder manuell per Apple Configurator aktiviert), ein iOS Update für einen beliebigen Zeitraum zwischen 1 und 90 Tagen zu verhindern. Bisherige Ansätze, wie bspw. das Blockieren der Verbindung zum Apple Update Server in einem Proxy, scheinen damit obsolet zu werden. Die Einstellung kann mit einem kompatiblen Mobile Device Management System auf die Geräte ausgerollt werden.

Vorteile der neuen Lösung

Die IT im Unternehmen erhält durch die neue Option vor allem mehr Zeit zum Test der neuen iOS Releases, bevor sie bspw. eine generelle Freigabe erteilen. Dies könnte sich insbesondere positiv beim Einsatz von unternehmenseigenen Apps auszahlen, da sich dann hier mehr Zeit zur Behebung von Bugs ergibt. Eine generelle Möglichkeit zur Verhinderung von iOS Updates gibt es weiterhin nicht und wird es meiner Meinung nach nicht geben.  


"Wi-Fi Password Sharing" in iOS 11 kann ggf. Risiko für Unternehmen sein

Geschrieben am 20. Jan 2018, 17:41

Apple hat im Januar 2018 den iOS Security Guide aktualisiert und Inhalte zu neuen Funktionen in iOS 11 ergänzt (siehe auch Apple aktualisiert iOS Security Guide für iOS 11). Ein neuer wesentlicher Absatz findet sich im Dokument, welcher in der Dokumentenrevision nicht erwähnt wird: "Wi-Fi Password Sharing". Die Funktion, welche für den Privateinsatz sehr hilfreich sein kann, kann für Unternehmensnetzwerke unter bestimmten Bedingungen Risiken erzeugen. Welche das sind, wird im Folgenden erläutert.

Erläuterungen zu "Wi-Fi Password Sharing"

"Wi-Fi Password Sharing" ermöglicht es, ein W-LAN Passwort zwischen befreundeten Geräten zu übertragen, so dass ein etwaiges W-LAN Passwort nicht erneut eingegeben werden muss. Dazu ist es notwendig, dass Bluetooth aktiviert, beide Personen sich jeweils in den Kontakte angelegt haben und die beiden Geräte nahe beinander sind (maximaler Abstand ca. 1 Meter). Nach Freigabe der Übertragung auf dem Gerät des Senders wird der W-LAN-Zugang zum Empfängergerät übertragen. Ein W-LAN-Zugriff ist fortan möglich. Die Funktion erscheint somit auf den ersten Blick hinsichtlich Komfort einen großen Mehrwert für den Nutzer zu bringen. Die Übertragung des W-LAN-Passworts (PSK, Pre Shared Key) geschieht per Bluetooth, wie die Erklärung von Apple aus dem Dokument aufzeigt: "Once identify is proven, the grantor sends the requestor the 64 character PSK, which can also be used to join the network." Der Umstand, dass lediglich der PSK (Pre Shared Key) des W-LAN übertragen wird, lässt darauf schließen, dass mit Zertifikaten abgesicherte W-LAN's (wie üblich in Unternehmen) davon nicht betroffen sind und somit potenziell keine Gefahr für die Sicherheit davon ausgeht. Eine Deaktivierung dieses Features lässt sich, laut dem Security Guide, mittels einer Mobile Device Management Lösung (MDM) erreichen: "Organizations can restrict the use of Wi-Fi password sharing for devices or apps being managed by using an MDM solution." Eine offizielle Einstellung dazu gibt es für die iOS-Konfigurationsprofile nicht. Eine Recherche meinerseits hat jedoch ergeben, dass zur Deaktivierung der Funktion AirDrop auf dem Gerät vollständig deaktiviert sein muss.

Risiko: W-LAN PSK in Konfigurationsprofilen

Wie oben erläutert, wird beim "Wi-Fi Password Sharing" der Pre-Shared-Key eines W-LANs auf ein befreundetes Gerät per Bluetooth übertragen. Einer Recherche nach trifft dies ebenfalls auf W-LANs zu, welche per Konfigurationsprofil und einer Mobile Device Management Lösung auf das Gerät gespielt wurden (vgl.: https://www.jamf.com/jamf-nation/discussions/25413/ios-11-wifi-sharing). Dies kann für W-LANs in Unternehmen ein Problem darstellen, sofern diese nicht per Zertifikat, sondern per PSK abgesichert sind. Die Risiken sind:

  • Wenn ein per MDM gemanagtes Gerät den PSK im iOS Konfigurationsprofil auf ein befreundetes Gerät überspielt, kann selbst bei Unkenntnis des W-LAN PSK somit ein fremdes Gerät dem Unternehmensnetzwerk beitreten.
  • Erhält ein befreundetes, aber nicht per MDM gemanagtes Gerät den W-LAN PSK, wird dieser über die iCloud Synchronisation auf fremde Gerät, bspw. ein macOS-Gerät übertragen. Das Passwort kann dann in der macOS Keychain eingesehen werden. Der W-LAN PSK ist damit nicht mehr sicher.

In beiden Fällen kann davon ausgegangen werden, dass entweder sich fremde Geräte in einem Netz befinden oder das Passwort für den Zugang bekannt wird. Eine Sicherheit ist dann nicht mehr gewährleistet.

Abhilfe nur durch AirDrop-Deaktivierung oder Umstellung auf zertifikatsbasierte Authentifizierung

Es gibt zwei mögliche Ansätze zur Behebung der Sicherheitsrisiken, wobei jedoch eine der beiden lediglich als Workaround zu sehen ist.

  • Workaround: Eine kurzfristige Eindämmung des Risiko's bringt die Deaktivierung von AirDrop auf gemanagten Geräten. Dazu sieht die iOS Konfiguration einen Parameter "allowAirdrop" vor, welcher AirDrop auf einem Gerät vollständig deaktiviert. Dann lässt sich "Wi-Fi Password Sharing" nicht mehr benutzen und ein W-LAN-Passwort somit nicht auf ein fremdes Gerät übertragen. Voraussetzung ist jedoch, dass das entsprechende iOS-Gerät "Supervised" ist, was nicht automatisch gegeben ist.
  • Langfristlösung: Aus Sicherheitsgründen sollte erwogen werden, ob der Zugriff zu einem Firmennetzwerk überhaupt noch auf einem Passwort basieren sollte oder ob die Umstellung auf zertifikatsbasierte Authentifizierung das Mittel der Wahl ist. Die Funktion "Wi-Fi Password Sharing" überträgt nach aktueller Wissenslage keine Zertifikate. Der Zugriff zu einem W-LAN wäre daher nicht gefährdet. Zudem bringt eine zertifikatsbasierte Authentifizierung weitere Vorteile mit sich, die insbesondere in Unternehmensnetzwerken Vorteile bringen (bspw. Widerruf einzelner Zertifikate, höhere Sicherheit).

Quellen:


Apple aktualisiert iOS Security Guide für iOS 11

Geschrieben am 20. Jan 2018, 16:51

Apple hat - etwas verspätet - den iOS Security Guide mit der Januar 2018 Ausgabe für iOS 11 aktualisiert. Das Dokument enthält umfassende technische Informationen zur Architektur der iOS-Devices sowie zu iCloud. Neu sind unter anderem Inhalte zu Face ID, welche bereits mit dem im November 2017 herausgegeben Face ID Security Guide erstmals veröffentlicht wurden.

Neue Inhalte gegenüber Vorversion

Der iOS Security Guide für iOS 11 (Januar 2018) enthält unter anderem folgende Inhalte gegenüber der Vorversion für iOS 10 (März 2017):

  • Apple Pay Cash
  • Security Certifications and Programs
  • Touch ID/Face ID
  • Shared Notes
  • CloudKit end-to-end encryption
  • TLS
  • Apple Pay, Paying with Apple Pay on the web
  • SiriSuggestions
  • Shared iPad

Die Januar 2018 Ausgabe des iOS Security Guides kann hier abgerufen werden: https://www.apple.com/business/docs/iOS_Security_Guide.pdf Quellen:


Die Sicherheit hinter Touch ID und Face ID

Geschrieben am 25. Oct 2017, 10:16

Mit der Vorstellung des iPhone X im September 2017, welches erstmals die neue biometrische Sicherheitsfunktion Face ID erhält, entflammen erneut Sicherheitsbedenken der Nutzer. Im Zentrum der Diskussion sind vor allem Datenschutzsorgen, da die iOS-Geräte nun entweder den Fingerabdruck (Touch ID) oder das Gesicht (Face ID) des Nutzers speichern. Der folgende Artikel soll mit weitläufigen (Negativ-)Gerüchten aufräumen und das Thema korrekt einordnen.

Was sind Touch ID und Face ID?

iOS-Geräte (iPhone, iPad) verfügen über biometrische Sensoren, welche in Verbindung mit der Software des Geräts den Zugriff auf das Gerät steuern. Folgende Varianten sind derzeit vorhanden:

  • Touch ID: ein Fingerabdrucksensor (CMOS-Sensor) liest das Fingerabdruckprofil ein und entsperrt bspw. das Gerät. Derzeit können bis zu fünf Finger hinterlegt werden.
  • Face ID: die Gerätekamera (TrueDepth-Kamera) auf der Vorderseite erfasst die Gesichtsgeometrie und entsperrt bspw. das Gerät. Derzeit kann nur ein Gesicht hinterlegt werden.

Wie helfen die Biometriefunktionen Touch ID und Face ID bei der Gerätebenutzung?

Die Biometriefunktionen sind kein vollständiger Ersatz des Gerätepassworts, sondern lediglich eine Ergänzung, und sollen die Gerätenutzung vereinfachen. Zur Nutzung von Touch ID oder Face ID muss immer ein Gerätepasswort vergeben sein. Touch ID und Face ID können in folgenden Fällen das Gerätepasswort ersetzen:

  • Entsperrung des iOS-Geräts
  • Bestätigung von Einkäufen im AppStore oder iTunes Store
  • Autorisierung von Zahlungsvorgängen mit Apple Pay
  • uvm.

In einer Reihe von Fällen jedoch ist die Eingabe des Gerätspassworts unumgänglich, bspw. nach einem Neustart des Geräts oder bei Änderung des Gerätepassworts.

Wie sicher sind Touch ID und Face ID einzuschätzen?

Die hinterlegten Fingerabdrücke sowie das Gesicht werden im so genannten "Secure Enclave" gespeichert. Hierbei handelt es sich um eine gesonderte Komponente des Prozessors, welche mit Fokus auf Sicherheit entworfen wurde.

Wahrscheinlichkeit gleicher Merkmale

Apple gibt die Wahrscheinlichkeiten, dass jemand mit einem vergleichbaren Fingerabdruck oder Gesicht das Gerät entsperren kann, wie folgt an:

  • Touch ID: 1 zu 50.000 (bei Hinterlegung eines Fingers!)
  • Face ID: 1 zu 1.000.000

Bezogen auf die Bevölkerung in Deutschland von rund 82 Millionen Menschen, gibt es rechnerisch gesehen ca. 1.600 Menschen mit ähnlichen Fingerabdruck- bzw. 82 Menschen mit ähnlichen Gesichtsmerkmalen.

Speicherung der Daten

Die hinterlegten Fingerabdrücke bzw. das Gesicht sind permanent in der "Secure Enclave" gespeichert und verlassen diese Komponente niemals. Findet beispielsweise ein Abgleichvorgang statt, senden die Sensoren die Merkmale des gescannten Fingers bzw. Gesichts an die "Secure Enclave". Die "Secure Enclave" gleich die Daten mit den gespeicherten Informationen ab und sendet lediglich ein binäres Ergebnis zurück: der gesendete Finger/ das Gesicht entspricht den Merkmalen hinterlegten oder nicht. Somit haben Apps niemals Zugriff auf die biometrischen Merkmale des Nutzers. Die Einseitigkeit der Verbindung zur "Secure Enclave", das heißt der Datenfluss erfolgt nur zur und nicht von der "Secure Enclave", drückt sich zudem in zwei weiteren Eigenschaften aus:

  • die gespeicherten Merkmale des Fingerabdrucks bzw. Gesichts werden niemals in die iCloud geladen und stehen lediglich auf dem betroffenen Gerät zur Verfügung
  • die gespeicherten Merkmale sind ebenfalls nicht in Backups enthalten - weder in iCloud Backups noch in lokalen Backups, welche bspw. mit iTunes angefertigt wurden

Bei der Hinterlegung der Merkmale (Gesicht, Finger) wird auf ein mathematisches Verfahren zurückgegriffen, um eine digitale Abbildung zu ermöglichen. Dieses mathematische Verfahren ist vergleichbar mit der Erstellung eines Hash-Wertes bei Passwörtern. Es ist Best-Practice, Passwörter in Datenbanken nicht im Klartext, sondern als Hash-Wert abzulegen. Ein Hash-Wert ist stark vereinfacht vergleichbar mit einer Quersumme. Die Quersumme einer Zahl ist eine reduzierte Abbildung der ursprünglichen Zahl, so wird aus der Zahl 32487 die Quersumme 24 (3+2+4+8+7 = 24). Es handelt sich dabei um eine Einwegfunktion, das heißt aus der Quersumme 24 lässt sich die urspürngliche Zahl (hier: 32487) nicht ermitteln. Die hinterlegten Merkmale des Fingers oder Gesichts werden somit durch das mathematische Verfahren so in der "Secure Enclave" gespeichert, so dass sich die ursprünglichen Fingerabdrücke bzw. Gesichtsmerkmale daraus nicht erzeugen lassen (bzw. nur mit sehr großem Aufwand!). Nicht zu vernachlässigen ist eine Berichterstattung über eine Patentschrift zur iCloud Synchronisierung von Fingerabdrücken (vgl. https://www.heise.de/mac-and-i/meldung/Touch-ID-iCloud-Sync-fuer-Fingerabdruecke-taucht-in-Apple-Patentschrift-auf-2518418.html). Zum aktuellen Zeitpunkt liegen noch keine Erkenntnisse darüber vor, ob eine solche Synchronisierungsmöglichkeit in naher Zukunft tatsächlich umgesetzt werden würde. Dies würde zumindest dem oben genannten Grundsatz, dass die Merkmale die "Secure Enclave" niemals verlassen, zumindest entgegen sprechen.

Möglichkeiten der Umgehung von Touch ID bzw. Face ID

Es gab in den letzten Jahren vermehrt Medienberichte über Möglichkeiten zur Umgehung von Touch ID (vgl. https://www.heise.de/security/meldung/Fingerabdrucksensor-des-iPhone-6-ueberlistet-2399891.html). Dabei wurden Fingerabdruckattrappen mit überschaubarem Aufwand reproduziert, um damit das iPhone entsperren zu können. Die Möglichkeit, unter Verwendung einer Attrappe den Sensor zu überlisten, erscheint bei genauerer Betrachtung nicht verwunderlich, denn die Attrappe bildet genau das nach, was sich am Finger befindet: das Profil bzw. die Erkennungsmerkmale. Dass eine nachgebaute Attrappe dann den Sensor überlisten kann, erscheint somit nicht verwunderlich. Rein theoretisch gesehen handelt es sich bei der Umgehung per Attrappe im engeren Sinn nicht um eine Lücke des Systems. Ein vergleichbarer Umstand würde entstehen, wenn jemand das Gerätspasswort (= den Passcode) ausspäht und ihn dann nutzt, um das Gerät zu entsperren. Es liegt folglich die Vermutung nahe, dass man Fotos nutzen könnte, um Face ID des iPhone X überlisten zu können. Dieser Lücke scheint zumindest konzeptionell bedacht worden zu sein. Face ID erfasst nicht nur das Gesicht und die Merkmale, sondern erfasst durch einen Infrarotsensor sogar die Gesichtsgeometrie (das heißt Proportionen, wie beispielsweise Höhenunterschiede zwischen Nase und Augen mittels eines Tiefenmodells). Ein Foto verfügt über keine nennenswerte Geometrie, da sich ein Foto komplett auf einer Ebene befindet. Der Sensor wird somit keine Höhenunterschiede feststellen können und eine Entsperrung per Foto erscheint damit unwahrscheinlich.

Fazit

Apple scheint bei der Implementierung von Sicherheit von Touch ID und Face ID nach aktuellem Kenntnisstand aus Sicht der physikalischen Sicherheit und des Datenschutzes den richtigen Ansatz gewählt zu haben. Die gespeicherten biometrischen Merkmale verlassen das Gerät niemals und werden mathematisch repräsentiert gespeichert, so dass die Originalmerkmale nicht zu rekonstruieren sind. Ob die vermeintlichen Lücken, die Erstellung einer Fingerattrappe, als Sicherheitsrisiko einzustufen ist, muss im Einzelfall geprüft werden. Eine Deaktivierung von Touch ID scheint an dieser Stelle keine Lösung zu sein, da auch ein eingespeichertes Gerätepasswort ausgespäht werden kann.

Quellen:


iOS-Geräte provisorisch zum Apple Device Enrollment Program hinzufügen

Geschrieben am 24. Sep 2017, 15:34

Mit der Veröffentlichung von iOS 11 sowie der gleichzeitigen Bereitstellung des Apple Configurator 2 (Version 2.5) am 19. September 2017 gibt es nun die Möglichkeit, iOS-Geräte provisorisch zum Apple Device Enrollment Program (DEP) einzubinden. Diese Möglichkeit bietet insbesondere für Unternehmen neue Chancen.

Was ist das Apple Device Enrollment Program (DEP)?

Dieser Apple Service richtet sich an Unternehmen und Schulen. Zentral beschaffte iOS-Geräte können im Apple DEP-Portal mit einem Mobile Device Management (MDM) Server verknüpft werden, was die Inbetriebnahme des Geräts durch automatisches Einhängen in den MDM-Server deutlich vereinfacht und größtmöglich automatisiert. Durch Nutzung von DEP in Verbindung mit MDM, kann zudem der so genannte "Supervised" Modus auf den Geräten Over-the-Air, d. h. ohne Betreuung durch die IT-Organisation, aktiviert werden. Supervised erlaubt es beispielsweise, die Geräte von Apple ID's zu entkoppeln und damit den Activation Lock auszuschalten. Dies erlaubt eine Wiederverwendung des Geräts, selbst wenn der Zugriff zur Apple ID nicht mehr vorliegen sollte. Weitere Informationen zu DEP gibt es hier: https://www.apple.com/business/dep/

Weshalb ist die neue provisorische DEP-Verknüpfung hilfreich?

iOS-Geräte konnten bisher nur über die folgenden zwei Wege in den DEP-Service integriert werden:

  • Beschaffung der Geräte über einen akkreditierten Apple-Reseller oder Mobilfunkprovider (leider gibt es keine öffentlich verfügbare Liste) ODER
  • Beschaffung der Geräte über Apple direkt

Zusätzlich steht der DEP-Service nur in einer geringen Anzahl von Ländern (siehe hier) zur Verfügung, was die Nutzung erheblich einschränkt. Beispielhaft sei mit Stand von heute (24. September 2017) erwähnt, dass Russland nicht zu diesen Ländern gehört und daher DEP dort nicht genutzt werden kann. Mit der neuen provisorischen DEP-Verknüpfung ist es nun möglich, iOS-Geräten in den DEP-Service von Apple einzuhängen, auch wenn diese nicht über einen der beiden oben genannten Wege bezogen wurden. Im Falle von Schulen können beipielsweise gespendete Geräte dann dem DEP-Bestand hinzugefügt werden.

Wie funktioniert die provisorische DEP-Verknüpfung?

Die provisorische DEP-Verknüpfung kann derzeit nur unter folgenden Bedingungen angewendet werden:

  • das iOS-Gerät ist mit iOS 11 ausgestattet und
  • der Apple Configurator 2 (in Version 2.5) wird verwendet.

Das iOS-Gerät wird unter Verwendung des Apple Configurator 2 zum DEP hinzugefügt. Das Hinzufügen zum DEP geschieht auf provisorischer Basis. Im Folgenden bedeutet dies:

  • Das iOS-Gerät erhält ein DEP Enrollment Profile und wird beim ersten Starten mit dem DEP-Server sowie dem hinterlegten MDM-Server verbunden.
  • Das DEP-Profil hat eine Gültigkeitsfrist von 30 Tagen (deshalb "provisorisch"). Innerhalb des Zeitraums kann das DEP-Profil vom Nutzer gelöscht werden (eine Löschung hat einen Factory Reset zur Folge).
  • Läuft der Gültigkeitszeitraum von 30 Tagen ab und das Profil wurde nicht vom Gerät entfernt, wird das Gerät dauerhaft dem DEP-Service hinzugefügt. Alle weiteren DEP-Funktionalitäten sind nun dauerhaft und in vollem Umfang zu nutzen.

Wie kann nun ein Gerät provisorisch zu DEP hinzugefügt werden?

Die folgende Bilderserie veranschaulicht den Enrollment-Prozess. Achtung: Durchführung des DEP-Enrollments mit einem iOS-Gerät und dem Apple Configurator führt zu einem Factory-Reset, bei dem alle Daten auf dem Gerät unwiederbringlich gelöscht werden! [gallery ids="151,156,152,153,154,155"] Nach Einhängen des Geräts in das DEP-System, zeigt sich bei der Inbetriebnahme ein neuer Installationsschritt 'Remote Management': [gallery ids="158,159"]

Was ist abschließend zu tun?

Nach Durchführung aller obigen Schritte gibt es keine weiteren Tätigkeiten. Nach Ablauf des 30-tägigen Gültigkeitszeitraums wird das Gerät permanent in das DEP-System bei Apple aufgenommen und alle Funktionen sind vollumfänglich nutzbar. Fazit: Das provisorische Hinzufügen von iOS-Geräten zum DEP-System bei Apple schließt eine bisher vorhandene Lücke. Durch den bis dato bestehenden Zwang, iOS-Geräte über akkreditierte Apple-Reseller oder Mobilfunkprovider beziehen zu müssen, war es Unternehmen nicht möglich, vorhandene iOS-Geräte dem DEP-System zu zuführen. Es ergeben sich nun folgende neue Möglichkeiten im Bereich der iOS-Nutzung für Unternehmen:

  • Es bestehen somit Migrationspfade, um eine bestehende iOS-Landschaft 'DEP-fähig' zu machen.
  • Unternehmen in Ländern, welche keine Möglichkeiten haben, Geräte von akkreditierten Apple-Resellern zu beziehen (bspw. Russland), können Geräte zu bestehenden DEP-Accounts hinzufügen.

Die von Apple hier geschaffene Möglichkeit scheint in erster Linie positiv zu sein, da sie es Unternehmen ermöglicht, von DEP auch kurzfristig zu profitieren. Ob jedoch der oben vorgestellte Weg hinsichtlich Geschwindigkeit und Flexibilität bei großen iOS-Landschaften mit mehreren tausend iOS-Geräten hinreichend gut skaliert, muss im Einzelfall erwogen werden. Quellen:


Julian Joswig

Julian Joswig Facebook Julian Joswig LinkedIn Julian Joswig Twitter Julian Joswig XING

Über diesen Blog

Was ist der Inhalt dieses Blogs, fragt ihr euch vielleicht? Mein Name ist Julian Joswig und ich bin großer Fan von IT und Technologie (hauptsächlich Linux, Server, Netzwerke und alle damit verbundenen Themen). Manchmal beiße ich mir an schwierigen Sachverhalten fast die Zähne aus. Habe ich jedoch eine Lösung gefunden, möchte ich diese mit der Welt teilen. Beruflich arbeite ich als Management Consultant in Deutschland mit Fokus auf IT und Business.

Neueste Artikel:

Artikelarchiv:

Twitter Timeline: