Auf dem iPhone und iPad gestattet Apple nur Apps, die über den App Store vertrieben werden - alle Programme müssen Apples Review-Prozess durchlaufen und den Apple Guidelines genügen. Sehr oft sorgt diese Überprüfung und das strenge Regelwerk für Probleme bei Entwicklern, ihre Apps in den App Store zu bekommen. Apple erreichte es durch den Review-Prozess und technische Vorkehrungen auf iOS (wie zum Beispiel der Sandbox, die Dateizugriffe auf die eigenen App beschränkt) aber, dass in den vergangenen 10 Jahren kaum Malware in Apps für iOS zu finden war.
Zum Start des Mac App Stores mussten Entwickler zwar auch einige Vorgaben erfüllen, aber Apps liefen noch ohne Sandbox und konnten fast alle Dateien im Dateisystem lesen und beschreiben - die Sandbox hielt aber mit Mac OS X 10.5 Leopard auch auf dem Mac Einzug und wurde Voraussetzung, um Apps im Mac App Store anzubieten - zum Unmut vieler Entwickler. Einige Entwickler von Apps, die inkompatibel zur Sandbox sind, verließen daraufhin den Mac App Store und vertreiben die Apps außerhalb.
"Developer ID" - Sicherheit für Anwender beim Download von Apps außerhalb des App StoresDa es auf dem Mac nach wie vor möglich ist, Apps auch außerhalb des Mac App Stores zum Download anzubieten, führte Apple "Developer ID" ein. Damit wird eine App vom Entwickler mit einer digitalen Signatur versehen, die sicherstellt, dass die App tatsächlich vom Entwickler selbst stammt und nicht von Dritten modifiziert wurde. So ist ausgeschlossen, dass ein Hacker eine App modifiziert und diese als Original-App anbietet - inklusive Malware. Gatekeeper stellt auf dem Mac sicher, dass die Apps korrekt signiert sind und erlaubt nur dann die Ausführung.
Developer ID hat aber einen entscheidenden Nachteil: Ist beispielsweise das Entwicklerzertifikat gestohlen worden oder hat sich durch einen Hack Schadcode in die App eingeschlichen (zum Beispiel wenn ein Hacker Zugriff auf den Mac des Entwicklers hatte), kann derzeitig nur das ganze Developer-ID-Zertifikat widerrufen werden. Alle Apps und alle App-Versionen des Entwicklers würden so aus dem Verkehr gezogen.
Grundsätzlich findet bei Developer ID keine Überprüfung von Apple statt - der Entwickler kann mit seinem Developer-ID-Zertifikat erst einmal signieren was er möchte. Nur wenn Apple im Nachhinein bekannt wird, dass mit dem Zertifikat auch Malware signiert wurde, kann Apple dies widerrufen.
"Notarized Apps" - feingranulare KontrolleApple erweitert nun das Developer-ID-System um einen weiteren Schritt: Nachdem der Entwickler eine digitale Signatur zu seiner App hinzugefügt hat, wird die App zu Apple hochgeladen. Apple analysiert diese und erhält bei Erfolg eine Art von digitalem Stempel, dass diese Version dieser speziellen App identifiziert. Danach kann der Entwickler die App außerhalb des Mac App Stores zum Download anbieten.
Das Vorgehen hat einen entscheidenden Vorteil: Sowohl der Entwickler wie auch Apple kann eine bestimmte Version einer App auf Kunden-Macs am Starten hindern - und nicht wie mit "Developer ID" das gesamte Portfolio des Entwicklers. Hat der Entwickler beispielsweise einen schwerwiegenden Fehler entdeckt oder ist durch einen Hack Malware in die App geraten, kann Apple und der Entwickler weiteren Schaden beim Kunden verhindern.
Die Überprüfung bei "Notarized Apps"Apple betonte auf einer WWDC-Session, dass es sich bei der Überprüfung nicht um den normalen Review-Prozess des App Stores handelt - vielmehr ist dies ein wahrscheinlich weitgehend automatisiertes Sicherheitsscreening, das ähnlich wie ein Virenscanner arbeitet und bekannte Malware identifiziert.
Trotzdem könnte dies ein erster Schritt sein, dass Apple die Daumenschrauben bei Apps anziehen möchte, die außerhalb des Mac App Stores vertrieben werden. So wäre es Apple möglich, auch die Nutzung von privaten APIs in Apps einzuschränken, die außerhalb des Mac App Stores vertrieben werden - im Mac App Store ist dies nicht erlaubt. Gelegentlich nutzen Entwickler nicht öffentliche Programmierschnittstellen, um Funktionen in Apps bereitzustellen, für die Apple keine Vorkehrungen anbietet. Das Screening der App könnte in Zukunft auch automatisch nach der Nutzung solcher privaten APIs suchen - und im Erfolgsfall das Ausstellen des digitalen Stempels verwehren.
"Notarized Apps" noch keine Pflicht - aber in Zukunft schonMit macOS 10.14 Mojave können Entwickler entweder weiterhin die "Developer ID"-Signatur oder "Notarized Apps" nutzen - allerdings kündigte Apple schon jetzt an, dass das "Notarized Apps"-Verfahren mit einer zukünftigen macOS-Version Pflicht wird, wenn der Entwickler seine Apps signieren möchte.
Vertrieb von unsignierten Apps und Open-Source-SoftwareNoch ist es möglich, Gatekeeper aus dem Terminal so einzustellen, dass weiterhin unsignierte Apps auf macOS ausgeführt werden können. Auch reicht es im Finder, mit einem Rechtsklick "Öffnen" bei einer unsignierten App auszuwählen, um diese zu starten. Der Nutzer wird zwar darauf hingewiesen, dass dies ein Sicherheitsrisiko darstellt, aber macOS führt danach die App normal aus.
"Developer ID" wie auch "Notarized Apps" können nur von Entwicklern genutzt werden, welche im Apple Developer Program registriert sind - dies kostet 100 Euro im Jahr. Viele Open-Source-Anwendungen werden daher völlig ohne digitale Signatur vertrieben - bisher kündigte Apple aber nicht an, dass dies in Zukunft eingeschränkt wird. Größere Open-Source-Projekte mit einem gewissen Grad an Finanzierung wie auch kommerzielle Apps trifft man kaum noch ohne digitale Signatur an - zu hoch ist der Sicherheitsgewinn im Vergleich zum Aufwand.
ZukunftsausblickMit "Notarized Apps" könnte Apple die Grundsteine gelegt haben, auch Apps außerhalb des Mac App Stores bestimmte Vorgaben zu machen - so beispielsweise die Nutzung von privaten APIs unterbinden, vorzuschreiben, dass die App in einer Sandbox zu laufen habe. Einerseits ist es für Endanwender wünschenswert, dass die Sicherheit der Plattform gewährleistet wird. Die Sandbox zum Beispiel unterbindet es verlässlich, dass eine gekaperte App die Fotos oder Dokumente eines Nutzers löscht oder ausließt.
Auf der anderen Seite bedeutet es für Entwickler viel Aufwand, zusätzliche Vorgaben zu erfüllen - manche Arten von Apps sind mit beispielsweise der Sandbox nicht zu realisieren. Auch Programme, die über private APIs das System modifzieren, wären so nicht mehr denkbar.
Die technischen Mittel, um dies komplett durchzusetzen, hat Apple mit dem iMac Pro eingeführt: Dessen T2-Chip besitzt die Möglichkeit, eine macOS-Installation vor dem Starten zu überprüfen und gegebenenfalls den Boot-Prozess zu verhindern, wenn die macOS-Installation modifiziert wurde. Auf diese Weise wäre es für Anwender nicht mehr möglich, Sicherheitsüberprüfungen in macOS durch Hacks zu deaktivieren, um von Apple nicht abgesegnete Apps auszuführen.
Noch ist dies nicht der Fall - der T2-Chip im iMac Pro lässt sich konfigurieren und Apps ohne Signatur sind mit einem kleinen Umweg weiterhin lauffähig. Es bleibt abzuwarten, ob Apple Sicherheit und Kontrolle über die Flexibilität stellt, jegliche Apps unter macOS ausführen zu können. Von letzterem profitieren nur ein kleiner Teil der Anwender - das Gros der Kunden würde von der Umstellung überhaupt nichts mitbekommen und wäre besser vor Malware geschützt.