-
Hintergrund der Erfindung
-
Bereich der Erfindung
-
Die vorliegende Erfindung betrifft Software und mobile Geräte. Insbesondere betrifft sie die Absicherung, die Beherrschung und Verwaltung von Apps auf Geräten, wie beispielsweise Handapparaten, Fernsehern, Automobilen, und anderen sich entwickelnden Smartgerätekategorien.
-
Beschreibung des Stands der Technik
-
Wie aktuell in der Industrie für Computer, mobile Handgeräte und Smartphone bekannt ist, taucht ein neues Computerparadigma auf und wird durch die Weiterentwicklung von Softwareanwendungen weiter vorangetrieben, die im Allgemeinen als Apps für Organizer oder mobile Geräte bekannt sind. Diese Weiterentwicklung ist direkt gekoppelt an den Einsatz von Smartphones und Tablets durch die Benutzer. Unternehmen erstellen nun ihre eigenen spezifischen Apps und verteile diese an Mitarbeiter, Kunden und Partner. Unternehmen schreiben nun ihre eigenen Apps zur Benutzung durch ihre Angestellten und Partner. Jedoch entsteht mit diesem Wachstum ein weiteres Problem und zwar der Sicherheit und Verwaltung dieser Apps auf mobilen Geräten. Apps können signifikante Schäden bei einem Handgerät verursachen und können zu Datenverlust oder ungewollte Übertragung von Daten führen. Sie stellen für die Geräte eine Schwachstelle dar und ein Sicherheitsrisiko für der Benutzer.
-
Herkömmliche Antivirenansätze, wie beispielsweise durch MyLookOut bereit gestellt entfernen keine Beschädigung die durch eine App auf einem Handgerät verursacht wurde. Obwohl das auf eine schwarze Liste setzten (bzw. blacklisting) von Apps teilweise für den Schutz der Geräte ausreichend ist (nicht nur Apps auf der Liste, die heruntergeladen werden können), wäre es besser, wenn es ein Verfahren geben würde, um den Schaden der durch eine, mit einem Schadprogramm infizierte App auf dem Gerät verursacht hat, eindämmen würde. Es wäre von Vorteil wenn der Kern des Softwarebetriebssystems des Geräts nicht verändert werden müsste. Es wäre auch von Vorteil, wenn der Autor der App nicht in der Art der sicheren Programmierung trainiert werden müsste oder etwas Spezielles oder angepasste für die Sicherheit programmieren (bzw. schreiben) müsste wenn er die App programmiert. – siehe sollten einfach in der Lage sein, Apps zu programmieren wie sie es momentan bereits machen. Es wäre auch von vorteil, das Geräte mit einem App-Sicherheitsverfahren verkauft oder entwickelt werden, das in die Funktionsweise des Gerätes integriert ist und das alle auf dem Gerät durchgeführten App-Sicherheitsmessungen für den Benutzer erkennbar wären.
-
Zusammenfassung der Erfindung
-
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Gerät mit einer App-Sicherheitsdurchsetzungsschicht vorinstalliert oder an einen Benutzer verkauft. Mit dieser Schicht kann der Verbraucher oder Benutzer unsichere Apps- die noch die Mehrzahl der Apps umfassen- herunterladen und kann die App auf dem Telefon auf eine sichere Art ablaufen lassen, wobei potenzieller Datenverlust oder andere Schäden an dem Gerät, wie beispielsweise einem Smartphone oder einem Tabletcomputer minimiert werden. Die Durchsetzungsschicht oder Maschine (bzw. Engine) wird durch einen App-Sicherheitsserviceprovider an den Hersteller des Gerätes zur Verfügung gestellt, der die Maschinen mit der Funktionalität (Software, Firmware, usw.) auf dem Gerät integriert. Auf diese Weise sind die Vorgänge, die die Apps auf dem Gerät sicher machen, für den Verbraucher erkennbar. Der Gerätehersteller ist in der Lage das Gerät als sicherer für das Herunterladen und Ausführen von Apps zu vermarkten als andere Geräte.
-
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zur Sicherung einer App zur Ausführung auf einem Gerät beschrieben. Eine App wird erworben oder auf ein Gerät für die Ausführung heruntergeladen. Der Gerätebenutzer führt die App aus. Eine Sicherheitsrichtlinie für die App gibt. Eine App-Sicherheitsdurchsetzungsschicht oder Maschine ermittelt ob es eine Sicherheitsrichtlinie für die App gibt. Falls es keine gibt, kann eine Standardrichtlinie auf dem Gerät verwendet werden. Die Richtlinie wird auf die App während der Ausführung angewendet. Während der Ausführung der Sicherheitsrichtlinie für die auszuführende App werden für alle Anfragen die durch die App an das Gerätebetriebssystem durchgeführt werden Sicherheitsüberprüfungen durchgeführt. Auf Grundlage der Sicherheitsüberprüfung kann eine der folgenden Aktionen durchgeführt werden. (a) der Anfrage kann erlaubt werden an das Betriebssystem weitergereicht zu werden, (b) die Anfrage an das Betriebssystem kann verbessert werden und dann an das Betriebssystem weitergereicht werden, (c) die Anfrage kann blockiert werden, oder (d) die App kann beendet werden und kann auch von dem Gerät entfernt werden.
-
Beschreibung der Figuren
-
Bezugnahmen werden auf die angehängten Figuren gemacht die einen Teil der Beschreibung darstellen und in denen beispielhaft bestimmte Ausführungsformen der vorliegenden Erfindung dargestellt sind:
-
1A ist ein Blockdiagramm das einen Überblick über den App-Kontrollvorgang der vorliegenden Erfindung zeigt;
-
1B ist ein Blockdiagramm das eine alternative Ausführungsform eines App-Kontrollvorganges der vorliegenden Erfindung zeigt;
-
2 ist ein Blockdiagramm das Komponenten eines App-Sicherheitsprogrammes gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
-
3 ist ein Flussdiagramm das einen Prozess zeigt um eine App sicher zu machen bevor sie auf das Gerät heruntergeladen wird gemäß einer Ausführungsform der vorliegenden Erfindung;
-
4 ist ein Flussdiagramm für ein Verfahren das in dem Richtlinienmanager gemäß einer Ausführungsform durchgeführt wird;
-
5 ist ein Flussdiagramm, das den Prozess der Ausführung einer Sicherheitsumhüllten App auf einem Handapparat oder mobilen Gerät gemäß einer Ausführungsform zeigt;
-
6 ist ein Diagramm einer Systemarchitektur des App-Sicherheitskontrollsystems gemäß einer Ausführungsform;
-
7 ist ein Blockdiagramm von Komponenten zur Absicherung einer App auf einem Gerät während der Ausführung gemäß einer Ausführungsform;
-
8 ist ein Flussdiagramm für ein Verfahren zur Absicherung einer App auf einem Gerät während der Ausführung der App unter Verwendung integrierter Funktionen des Gerätes gemäß einer Ausführungsform; und
-
9A und 9B sind Blockdiagramme eines Computersystems die zur Implementierung verschiedener Ausführungsformen der vorliegenden Erfindung geeignet sind.
-
Detaillierte Beschreibung der Figuren
-
Beispielhafte Ausführungsformen eines Anwendungssicherheitsverfahrens und Systems sind beschrieben. Diese Beispiele und Ausführungsformen dienen nur dazu, um einen Kontext und eine Hilfe bei dem Verständnis der Erfindung bereitzustellen. Auf diese Weise ist es für den Fachmann offensichtlich, dass die vorliegende Erfindung mit einigen oder allen hierhin beschriebenen bestimmten Details ausgeführt werden kann. Bei anderen Beispielen sind bekannte Konzepte nicht im Detail beschrieben, um eine unnötige Verwirrung der vorliegenden Erfindung zu vermeiden. Weitere Anwendungen und Beispiele sind möglich, so dass die folgenden Beispiele, Darstellungen und Zusammenhänge nicht als abschließend oder begrenzend weder im Umfang noch Zusammensetzung aufzufassen sind. Obwohl die Ausführungsformen ausreichend im Detail beschrieben sind, um dem Fachmann zu ermöglichen die Erfindung auszuführen, sind die Beispiele, Darstellungen und Zusammenhänge nicht begrenzend und andere Ausführungsformen können verwendet werden und Änderungen können durchgeführt werden ohne von dem Wesen und Bereich der Erfindung abzuweichen.
-
Verfahren und System zur Verhinderung der Infizierung oder anderweitiger Beschädigungen eines Gerätes, insbesondere ein mobiles Gerätes, durch Gerätesoftwareanwendungen sind in den verschiedenen Figuren beschrieben. Diese Art von Anwendungen, die häufig auf einer Vielzahl von mobilen Geräten, wie beispielsweise Smartphones, Tabletcomputern, Spielegeräten und transportablen Computern verwendet werden, werden üblicherweise als „Apps” bezeichnet. Diese Apps können auch auf nicht mobile Geräte wie beispielsweise Fernseher, Computer, Automobile und andere sich weiter entwickelndes Smartgerätekategorien heruntergeladen werden. Verfahren und Systeme die beschrieben sind, sind nicht dazu gedacht auf eine Ausführung auf mobilen Geräten begrenzt zu sein. Diese Geräteprogramme oder Apps haben sich stark vermehrt und sind nun sehr weit verbreitet. Momentan werden Apps typischerweise entweder in Java oder C programmiert. Die hierhin beschriebenen Verfahren und Systeme können auf Apps angewendet werden die in einer dieser (Sprachen) programmiert sind oder auf Apps die in anderen Programmiersprachen für unterschiedliche Plattformen programmiert sind angewendet werden. Die meisten Apps, wenn nicht alle, müssen mit dem Betriebssystem des mobilen Geräts kommunizieren um einen bestimmten Service (bzw. Dienst) zu erhalten die die App benötigt um ihre vorgesehene Funktion durchzuführen und dieser Service ist für gewöhnlich nur von dem Betriebssystem verfügbar. Ein typisches Beispiel eines solchen Services der verwendet wird ist GPS um die Position des Gerätes zu erhalten, die die App benötigen könnte. Jedoch sind Apps aufgrund dieser Beanspruchung eine Schwachstelle für das Gerät und stellen eine Sicherheitsrisiko und ein Risiko für die Privatsphäre des Benutzers dar. Firmen wollen in der Lage sein, eine zentrale Richtlinie durchzusetzen um den Zugang zu ihren Daten und ihrer Software zu kontrollieren und abzusichern. Dies gilt auch für Endbenutzer (d. h. Einzelbenutzer, Heimanwender, und dergleichen). Dies ermöglicht Unternehmens-IT-Abteilungen die Kontrolle von Unternehmensdaten aufrecht zu erhalten. Die weiter unten beschriebenen Verfahren stellen einen zentralen Weg zur Kontrolle der Sicherheit bezüglich Apps die auf mobile Geräte heruntergeladen werden zur Verfügung, für den Fall das die Geräte entweder persönliche Telefone von Mitarbeitern oder ein Mitarbeitertelefon sind, so dass diese Apps nicht eine Sicherheitsgefahr darstellen. Verschiedene Ausführungsformen der Erfindung können auch durch Eltern oder Einzelpersonen (d. h. zu Hause oder in Nicht-Arbeitsumgebungen) benutzt werden, um sicher zu stellen, dass deren persönlichen mobilen Geräte sicher vor Schadprogrammen sind und kann auch dazu verwendet werden Kontrollen, wie beispielsweise über die Benutzung, durchzuführen. Ausführungsformen der App-Steuerungssoftware der vorliegenden Erfindung können auch für die Datensicherung, Backup und Telemetrie auf Applikationseben der mobilen Geräte verwendet werden.
-
1A ist ein Blockdiagramm das einen Überblick über das App-Kontrollverfahren der vorliegenden Erfindung darstellt. Dies stellt eine allgemeine Beschreibung eines Verfahrens dar, ohne auf eine spezifische Konfiguration oder Umgebung festgelegt zu sein. Eine App 102 wir von einem App-Provider 100 bereit gestellt, der jede Art von Einheit sein kann (Einzelperson, Softwareentwickler, Arbeitgeber, usw.). Sie ist grundsätzlich ungeschützt und die einzige Sicherheit die sie umgibt, wird durch das Betriebssystem bereit gestellt. Die einzige Abschirmung und Überprüfung die erfolgt wie sie auf dem Gerät ausgeführt wird, sobald sie geladen ist, wird durch das Betriebssystem bereit gestellt.
-
Die vorliegende Erfindung ermöglicht eine zusätzliche Sicherheit der Apps die nicht durch das Betriebssystem des Gerätes bereit gestellt wird. Ein Sicherheitsanwendungsprogramm 104 wird auf die App 102 angewendet. Oder die App 102 ist eine Eingabe für ein Programm 104, das von einem Dritten App-Sicherheitsprovider bereitgestellt werden kann. Gemäß einer Ausführungsform weist das Sicherheitsanwendungsprogramm 104 einen Richtlinienmanager und ein Richtlinien-Wrapper (bzw. Umhüller) auf, die sich an verschiedenen Stellen befinden können. Diese sind näher in 2 beschrieben. Sobald das Sicherheitsprogramm 104 auf die App 102 angewendet wurde ist die App mit einer Sicherheitsschicht umhüllt, so dass das Gerät geschützt ist. Diese ist als gesicherte App 106 dargestellt. Gemäß einer Ausführungsform wird die gesicherte App 106 dann auf ein mobiles Gerät 108, wie beispielsweise ein Smartphone oder ein Tabletcomputer, heruntergeladen wo sie sicher ausgeführt wird ohne eine Beschädigung des Gerätes 108 zu riskieren. Ein weiterer Vorteil ist, dass die gesicherte App 106 auch durch die Firma oder eine andere Einheit, die die App dem Benutzer bereit stellt, verwaltet werden kann, wie beispielweise ein Arbeitgeber der die App einem Arbeitnehmer bereitstellt. Beispielsweise kann, falls der Benutzer die Firma verlässt, die Firma automatisch die App und die damit verbundenen Daten von dem Gerät löschen. Bei einem anderen Beispiel könne Eltern in der Lage sein, die Apps einzuschränken die von anderen Personen z. B. einem Kind benutzt werden oder die Benutzungszeit zu limitieren und zu begrenzen, z. B. auf 10 Minuten pro Tag, oder sie können einschränken, auf welche Webseiten von der App zugegriffen werden kann. Oder Eltern können besorgt sein, dass eine App den Aufenthaltsort eines Kindes an unbekannte Dritte durchsickern lässt. Es kann eine Vielzahl von weiteren Beispielen geben. Wie angemerkt dient die 1A dazu, den allgemeinen Ablauf zur Sicherung einer App und dem Herunterladen dieser auf einem Gerät darzustellen. Es ist anzumerken, dass in dieser Ausführung die App 102 nicht gegen Verursachung von Schaden auf dem Gerät sicher gemacht nachdem sie auf das Gerät heruntergeladen wurde, sondern zuvor. Bei einer anderen Ausführungsform wird die App gesichert nachdem sie auf das Gerät heruntergeladen wurde, aber bevor sie mit dem Betriebssystem interagieren kann.
-
1B ist ein Blockdiagramm das eine alternative Ausführungsform darstellt. Eine ungesicherte App 110 (ebenfalls zur Verfügung gestellt durch einen App-Provider) wird auf ein mobiles Gerät 112 heruntergeladen. Bei dieser Ausführungsform kann jedoch eine speziell entworfene App auf dem Gerät 112 vorhanden sein, das die eigentliche Installation der ungesicherten App 110 blockiert. Die spezielle App (nicht dargestellt) leitet die ungesicherte App 110 an ein App-Sicherheitsprogramm 114 weiter. Die ungesicherte App 110 wird in einer Sicherheitsrichtlinie gepackt, die resultierende App ist als gesicherte App 116 dargestellt. Anschließend wird diese heruntergeladen und durch die spezielle App wird erlaubt, dass diese auf dem Gerät 112 installiert wird. Auf diese Art kann eine Einzelperson oder Heimanwender, z. B. der sein Telefon vor Sicherheitsbedrohungen in Folge von Apps schützen will, kann Apps durch einen Service Dritter oder durch Mobilfunkbetreiber, um nur zwei Beispiele zu nennen, sicher machen lassen (umhüllen) bevor diese auf sein Telefon heruntergeladen werden. Es ist anzumerken, dass diese Sicherheitsumhüllung auf jede App angewendet werden kann, unabhängig davon woher der Benutzer die App herunterlädt. Es kann auch angemerkt werden, dass in den 1A und 1B das Netzwerk und die Verbindungen zwischen den Komponenten und der Software allgemein dargestellt sind. Die Übertragungen erfolgt primär über das Internet (nicht dargestellt), kann aber auch innerhalb eines privaten Netzwerkes oder beiden stattfinden.
-
2 ist ein Blockdiagramm das Komponenten eines App-Sicherheitsprogramms gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. In einer Ausführungsform hat das Sicherheitsprogramm zwei Hauptkomponenten, einen Richtlinienmanager und einen Richtlinienwrapper bzw. Richtlinienadapter. Ein Richtlinienmanager 202 akzeptiert Eingaben von einem Administrator oder einem anderen Individuum das für die Einstellung der Sicherheit auf dem Gerät verantwortlich ist. Diese Person kann als der Regulator (oder Gouverneur) bezeichnet werden, der die Sicherheit des einen oder mehreren mobilen Geräte regelt. Die Sicherheitsrichtlinien können unter Verwendung verschiedener Benutzerbildschirme eingestellt werden. Es gibt eine Vielzahl von Beispielen für Richtlinien, inklusive geofencing (z. B. die App kann nur innerhalb eines Gebäudes benutzt werden) und anderen. Der Serviceprovider oder die Instanz, die dieses App-Sicherheitsprogramm zur Verfügung stellt, kann auch Standardrichtlinien oder Sicherheitseinstellungen zur Verfügung stellen die für Heimanwender sinnvoll sind. Beispiele für Richtlinieneinstellungen werden weiter unten beschrieben. Die Richtlinieneingabe 204 wird in den Richtlinienmanager 202 eingegeben. Der Richtlinienmanager 202 verwendet die Eingabe/Einstellungen von dem Regulator und erzeugt Richtlinien oder Metadaten 206. Das Format oder die Form der Metadaten 206 können variieren. Sie stellen im Wesentlichen die Richtlinieneinstellungen von dem Regulator dar.
-
Die Metadaten (Richtlinien) 206 können als Eingabe für einen Richtlinienwrapper 208 verwendet werden. Nach einer Ausführungsform verwendet diese Komponente des Programms die Richtlinien und benutzt diese um eine App 210 abzusichern, indem sie diese umhüllt bzw. einpackt. Der Wrapper 208 empfängt eine App 210 von einem Handgerät 212. Nach einer Ausführungsform empfängt der Wrapper 208 eine Kopie der App 210 an Stelle der Original-App 204 die auf das Telefon 212 heruntergeladen wurde (siehe 1B oberhalb). In diesem Fall versucht der Handgeräte 212 -Benutzer eine ungesicherte App 216 von einem App-Provider 218 herunter zu laden. Bei dem Szenario das in 1A beschrieben ist kann es (das Programm) an der App selbst ausgeführt werden, an Stelle einer Kopie. Dies kann der Fall sein, bei dem ein Marktplatz oder App-Store Benutzern eine abgesicherte Version der App zusammen mit einer ungesicherten Version anbietet (oder nur die ungesicherte Version anbietet). Eine abgesicherte Version 220 (Sicherheitsumhüllte Version) wird von dem Richtlinienwrapper 208 an das Gerät 212 zurück gegeben.
-
Metadaten 206 können auch verwendet werden um eine lokale Richtliniendatei (eine bestehende Richtlinie die bereits auf dem Gerät vorhanden ist) zu aktualisieren. Eine lokale Richtliniendatei wird verwendet um Richtlinienparameter, die sich auf dem Gerät 212 befinden, zu aktualisieren. Beispielsweise für den Fall das geofencings (d. h. die Beschränkung der Benutzung einer App auf einem bestimmten physikalischen Bereich) ist es wahrscheinlich, dass die von dem Regulator kontrollierte GPS-Position sich mit der Zeit ändern wird. Wenn solch ein Wechsel stattfindet kann die neue Richtlinie auf zwei verschiedene Arten angewandt werden. Eine davon ist eine neue Richtlinie zu erzeugen und diese auf die originale App anzuwenden (d. h. die App mit der neuen Richtlinie zu umhüllen). Ein weiterer Weg ist es, eine dynamisch Konfiguration basierend auf einer lokalen Richtliniendatei mit dem variablen Teil der Richtlinie verschlüsselt/signiert innerhalb dieser zu erlauben. Beispielsweise kann eine IT-Person die Möglichkeit wollen, die Konfiguration auf einem Gerät direkt über ein IT-App, die auf dem Gerät für Diagnosezwecke vorhanden ist, zu überschreiben.
-
Bei einer Ausführungsform haben die Richtlinien zwei Komponenten: einen festen Teil und einen variablen Teil. Der feste Teil ist der Bestandteil der in der Richtliniendatei beschrieben ist (z. B. schütze das GPS zu bestimmten Tageszeiten). Der variable Teil wird für gewöhnlich durch den Regulator über eine Konsole bereit gestellt (z. B. was sind die Zeiten zu denen des GPS geschützt werden soll?). Der variable Teil kann sich ändern ohne eine neue Richtlinie anzuwenden.
-
Richtliniendesigner können wählen, auf den variablen Teil der Richtlinie zu verzichten und grundsätzlich alle Daten oder Inhalte statisch in die Richtliniendatei einzubinden. In diesem Fall gibt es für die Konsole keine Möglichkeit die Richtlinie auf irgendeine Art anzupassen.
-
Falls der Richtliniendesigner sich entscheidet einige variable Komponenten in die Richtlinie aufzunehmen, kann, wenn Änderungen an den variablen Daten (auf der Konsole) vorgenommen werden, eine neue Datendatei an das Gerät gesendet werden um die letzten Änderungen zu reflektieren. Eine solche Datei wäre verschlüsselt/signiert (um zu verhindern, dass eine bösartige App die Richtlinie umgeht), würde auf das Gerät heruntergeladen, und durch den App-Sicherheitscode auf dem Gerät verwendet werden um die neuen Daten auf die entsprechende Richtlinie anzuwenden.
-
Solche Änderungen und Aktualisierungen können durch die lokale Richtlinienaktualisierungskomponente 222 zur Laufzeit erfolgen. Diese Komponente erzeugt aktualisierte Richtlinienparameter auf dem Gerät 212. Anschließend wird die umhüllte App 220 die aktualisierten Richtlinienparameter verwenden.
-
Bei einer Ausführungsform sind der Richtlinienmanager 202 und der Richtlinienwrapper 208 Komponenten in dem gleichen App-Sicherheitsprogramm und können auf dem gleichen Computer arbeiten. Bei einer anderen Ausführungsform können sich die Manager- und Wrapperkomponenten auf separaten Computern befinden. Beispielsweise kann der Richtlinienmanager 202 auf einen Server an einem Ort sein und der Richtlinienwrapper 208 kann auf einem Computer an einem anderen Ort sein und kann durch eine andere Einheit der gleichen Einheit verwaltet werden. Gemeinsam bilden der Manager und der Wrapper das App-Sicherheitsprogramm, welches bei einer Ausführungsform durch einen Sicherheitsserviceprovider betrieben wird. Es kann auch durch ein Unternehmen wie bspw. eine Firma, einen Arbeitgeber, einen Businesspartner und dergleichen oder durch einen Mobilfunkbetreiber zur Verfügung gestellt werden.
-
3 ist ein Flussdiagramm das einen Vorgang zeigt, eine App sicher zu machen bevor sie auf das Gerät heruntergeladen wird, gemäß einer Ausführungsform der vorliegenden Erfindung. Bei Schritt 302 wird eine Kopie oder Klone der App die zu sichern ist auf dem Gerät hergestellt. Bei einer Ausführungsform kann dies durch das mobile Gerät selbst erfolgen oder außerhalb des Gerätes, beispielsweise in den Komponenten im Internet, in der Cloud oder auf einem Unternehmensserver oder einem Betreiberserver erfolgen. Der Benutzer kann eine Einzelperson, ein Mitarbeiter einer Firma oder ein andere Einheit sein. Wie in dem Bereich bekannt ist, kann eine App auf verschiedene Arten erhalten werden, in den meist typischerweise von einem App-Store oder einem App-Marktplatz oder direkt von dem App-Entwickler oder Betreiber oder auf andere geeignete Weise. Durch Herstellen einer Kopie wird die Original-App bewahrt um dem Benutzer die Möglichkeit zu geben, entweder die abgesicherte oder die ungesicherte Version zu benutzen und nutzt auch die Möglichkeit des Benutzers die App zu benutzen, falls etwas in dem App-Kontrollprozess schief geht. Es ist anzumerken, dass bei einer Ausführungsform die App jetzt noch nicht auf das Telefon herunter geladen wird. Bei einer Ausführungsform werden die Verfahren die weiter unten beschrieben sind auf einem separaten Computer durchgeführt. In einer anderen Ausführungsform kann das Verfahren auf dem mobilen Gerät durchgeführt werden, aber die App wird auf dem Gerät nur ausgeführt nachdem das Verfahren vollständig ist und die App sicher gemacht wurde.
-
Bei Schritt 304 wird die App entkapselt (bzw. ausgepackt). Die meisten, wenn auch nicht alle Apps haben digitale Signaturen die durch den Autor oder Entwickler signiert sind. Bei Schritt 304 wird als Teil der Entkapselung die digitale Signatur von der App entfernt. Dies kann durch Techniken erfolgen die bekannt sind. Ein Entschlüsseln der App kann auch bei diesem Schritt erfolgen. Diese und weitere Schritte stellen den Objektkerncode der App zur Verfügung, der nun durch das App-Kontrollprogramm weiterverarbeitet werden kann. Die Art und einzelnen Besonderheiten dieses Vorgangs können von dem Betriebssystem des mobilen Geräts abhängen.
-
Es gibt verschiedene Beispiele für Betriebssysteme für Smartphones wie z. B. iOS (für das IPhone), Android (verwendet auf Handgeräten von verschiedenen Herstellern), Windows Mobile 7, Web O/S, Palm und andere. Bei Schritt 306 wird der Objektcode der Kern-App entweder disassembliert oder dekompiliert um den ausführbaren Objektcode zu erhalten. Beispielsweise kann dies entweder nativer Code (CPU Anweisungen) oder Bytecode (virtuelle Maschinenanweisungen wie bspw. Java oder .Net) sein. Bei einer Ausführungsform kann dies mehr ein Änderungsprozess sein, falls das Gerät unter iOS betrieben wird, bei dem das Disassemblieren mehr ein Verfahren der Erkennung und Ersetzung bestimmter Verweise und Ausdrücke ist. Jedoch kann im Allgemeinen der Dissasemblierungsprozess um den Objektcode einer App zu erhalten, nachdem diese entkapselt wurde, durch Techniken folgen die bekannt sind, wie bspw. die Verwendung von Dissasemblern.
-
Bei Schritt 308 wird der Objektcode der App mit Objektcode von dem App-Sicherheitsprogramm erweitert. Beispielsweise kann der Objektcode Klassendateien enthalten welche durch Klassendateien von dem Sicherheitsprogramm ersetzt werden. Der Objektcode stellt im Allgemeinen eine Schnittstelle an das Betriebssystem des Mobilgeräts bereit. Der Objektcode des App-Kontrollsicherheitsprogramms ist in Teilen von den Richtlinien/Metadaten abgeleitet. Für den Fall von iOS ist dieser Vorgang unterschiedlich als das mehr ein „erkennen und ersetzten” – Vorgang erfolgt als eine Ersetzung von Objektcode. Dies berücksichtigt eine Interrupt-Vorgehensweise, die von iOS verwendet wird. Im Allgemeinen arbeitet sich das App-Sicherheitsprogramm durch den Objektcode. Die speziellen Elemente die erkannt werden sind Softwareinterrupts (SWIs) innerhalb des Objektcodes, die durch einen Abzweig (bzw. Branch) an eine App-Steuerungssicherheitsprogrammebene ersetzt werden, welche dann bestimmen kann welche weiteren Aktionen durchzuführen sind, wie beispielsweise die Anfrage durchzuführen ist, die Ergebnisse zu verbessern, und andere wie weiter unten beschrieben.
-
Bei Schritt 310 bereitet das App-Sicherheitsprogramm, nachdem die Ersetzung des Programmcodes (oder Ersetzung von SWIs) durchgeführt wurde, die Sicherheitsumhüllte App für die Ausführung auf dem Mobilgerät vor. Der Objektcode der innerhalb der App durch das Sicherheitsprogramm ersetzt wurde, stellt im Allgemeinen eine Brücke oder Verbindung zwischen der App und dem Betriebssystems bereit. Die Klassendateien des Sicherheitsprogramms können als ein Umhüllen der Klassendateien des Betriebssystems beschrieben werden. Die Klassendateien des App-Sicherheitsprogramms werden auf Grundlage der zuvor erzeugten Richtlinien (durch Eingabe von dem Regulator) erzeugt. Die App wird für die Ausführung auf dem Handgerät im Wesentlichen neu verlinkt. Sie wird neu verlinkt um die App-Sicherheitsprogramschicht zusätzlich zu der von dem Betriebssystemschicht des mobilen Geräts bereitgestellten Sicherheit, zu benutzen. Das heißt, dass die abgesicherte App Gegenstand der Sicherheitsmaßnahmen des Betriebssystem sein kann. Bei einer Ausführungsform können auch bestimmte kosmetische Änderungen an der App durchgeführt werden, wie bspw. die Änderung des Icons der App um darzustellen, dass diese abgesichert ist. Durch diese Maßnahme kann der Benutzer sicher sein, dass wenn das App Icon auf dem Bildschirm des Handgerätes erscheint die abgesicherte Version der App ausgeführt wird. Die App ist nun durch das Sicherheitsprogramm grundlegend neu hergestellt oder neu programmiert.
-
Bei Schritt 312 wird die App mit einem neuen Schlüssel signiert, z. B. mit dem Schlüssel des Serviceproviders oder dem Schlüssel des Unternehmens das die gesicherte App bereit stellt. Die neu hergestellte, abgesicherte Version der App wird an das Handgerät zurückgegeben. Bei einer weiteren Ausführungsform wird die App mit der Sicherheitsschicht auf dem Telefon umhüllt. Bei Schritt 314 wird bei einer Ausführungsform das Original, die ungesicherte Kopie der App von dem Handgerät gelöscht. Dies kann durch die gesicherte Version der App erfolgen sobald diese auf das Handgerät heruntergeladen ist. Bei anderen Ausführungsformen erfolgt dies nicht und beide Versionen bleiben auf dem Mobilgerät. Zu diesem Zeitpunkt ist der Prozess abgeschlossen.
-
4 ist ein Flussdiagramm eines Verfahrens das in dem Richtlinienmanager 202 gemäß einer Ausführungsform ausgeführt wird. Bei Schritt 402 wird der Regulator oder andere Sicherheitsrichtlinienindividuen ermöglicht Sicherheitsrichtlinien zu definieren, zu erzeugen und zu erstellen. Dies kann ein Netzwerkadministrator eines Unternehmens sein, der für eine große Reihe von Mobilgeräten Sicherheitsrichtlinien für hunderte von Angestellten, die Dutzende von Unternehmens-Apps benutzen (speziell für die Arbeit), die auf Hunderte oder Tausende von mobilen Geräten herunter geladen werden können, entscheiden. Auf der anderen Seite des Spektrums können es Eltern sein, die die Sicherheitsrichtlinien für drei oder vier Apps einstellen, die von ihren Kindern auf ein neues Mobilgerät herunter geladen wurden. Andere Beispiele beinhalten, das Verhindern oder Unterdrücken eine Spiele-App das GPS zu verwenden, das Unterbinden einer App ein Mikrofon auf dem Gerät zu benutzen um eine Unterhaltung aufzunehmen oder zu belauschen, unter vielen anderen. In allen Fällen kann der Regulator die Kategorie der App, den Typ und die Art der App, den Autor, die Alterseignung und viele anderen Faktoren berücksichtigen. Beispielsweise ob der gleiche Autor andere Apps geschrieben hat, die als Schadprogramm eingestuft wurden oder ein Sicherheitsproblem für ein Gerät darstellen. Es kann erkennen ob es weitere Apps von dem gleichen Autor gibt. Zu diesem Zeitpunkt entscheidet der Regulator welche Regeln für jede App anzuwenden ist. Bei einer Ausführungsform erfolgt dies Rechnerunabhängig durch den Regulator. Das heißt, dies kann durch Benutzerschnittstellen auf einem Heimcomputer oder auch einem Unternehmensnetzwerkrechner der von einem Administrator verwendet wird erfolgen, wobei Sicherheitsvorlagen die von dem Sicherheitsprovider zur Verfügung gestellt werden (im Wesentlichen Standardvorlagen) verwendet werden oder sehr spezielle Regeln können unter Verwendung der Vorlagen erst eingestellt werden.
-
Bei Schritt 404 wird die Sicherheitsdateneingabe bei Schritt 402 durch das App-Kontrollsicherheitsprogramm verwendet, um die aktuellen Richtlinien zu erzeugen. Bei Schritt 406 wird der Objektcode des App-Kontrollsicherheitsprogramms basierend auf der Eingabe des Regulators bezüglich der Sicherheitsrichtlinien, die bei Schritt 404 erzeugt wurden, erzeugt. Der Regulator oder Serviceprovider kann falls nötig auch bestehende Sicherheitsrichtlinien aktualisieren. Wie zuvor beschrieben, kann der Objektcode verwendet werden, um bestimmten Originalobjektcode, der von der disassemblierten App erhalten wurde, zu verbessern. Der Verbesserungscode wird eingebracht, um Sicherheits- und Privatsphäre-Einstellungen für eine App anzupassen, um das Unternehmen und den Endbenutzer zu schützen. Das Verhalten der Original-App wird verändert, was dem Regulator ermöglicht zu kontrollieren, wie sich die App verhält. Falls beispielsweise eine App sensitive Accountinformationen im Klartext speichert (das heißt unverschlüsselt), kann das Verhalten verändert werden, so dass alle Informationen, die die App erzeugt, in verschlüsselter Form gespeichert werden und auf die nur durch die App zugegriffen werden kann, soweit der Schlüssel zu den gespeicherten, persistenten Daten eindeutig mit der App übereinstimmt. Bei vielen Beispielen kann der Verbesserungscode die Performance der App verbessern, da der Code für spezielle Benutzungsszenarien optimiert ist.
-
5 ist ein Flussdiagramm, das einen Prozess der Ausführung einer sicherheitsgepackten App auf einem Handgerät oder mobilen Gerät gemäß einer Ausführungsform zeigt. Bei Schritt 502 wird das Verhalten der App, wenn sie abläuft oder kurz unmittelbar bevor sie abläuft, auf dem Gerät verändert oder modifiziert. Beispielsweise kann die Modifikation die Authentifizierung während der App-Initialisierung beinhalten; zum Beispiel Smart/CAC-Karte oder Passwort-Aufforderung. Einige Apps verlangen, wie ursprünglich entworfen, kein Passwort für die Sicherheit, jedoch kann eine abgesicherte Version einer App, die modifiziert wurde, erfordern, dass der Benutzer ein Passwort eingibt. Bei Schritt 504 läuft die abgesicherte App durch Aktivierung des Benutzers auf dem Mobilgerät ab (zum Beispiel durch Antippen des Icons, falls das Gerät einen Touch-Screen hat). Auf die Aktivierung der App hin, kann die Steuerung gemäß einer Ausführungsform eine von vier Optionen haben. Wie allgemein bekannt ist, führt eine App, wenn sie ausgeführt wird, Abfragen oder Anfragen an das Betriebssystem des Gerätes aus, um seine Funktionen auszuführen. In vielen Fällen können diese Anfragen harmlos sein oder kein signifikantes Sicherheitsproblem an das Telefon oder Gerät darstellen. Falls dies der Fall ist, wird der Anfrage erlaubt, zu dem Betriebssystem zu gelangen, wie in Schritt 506 gezeigt ist. Hier erfolgt die Anfrage an das Betriebssystem des Gerätes und die App wird auf eine normale Art ausgeführt.
-
Falls die Sicherheitsschicht oder Umhüllung (bzw. Wrapper) um die App erkennt, dass die App eine Anfrage durchführt, die eine Sicherheitsgefahr für das Gerät darstellt, kann die App-Sicherheitsschicht die Anfrage verbessern oder modifizieren, bevor Sie an das Betriebssystem oder andere Software- oder Hardwarekomponenten in dem Telefon weitergegeben wird. Dies ist bei Schritt 508 dargestellt. Gemäß einer Ausführungsform erkennt der Regulator, welche Anfragen durch Ausführung einer oder mehrerer Richtlinien erlaubt sind. Beispielsweise kann der Regulator ermitteln, dass alle Daten in verschlüsselter Form gespeichert werden sollen. Bei einem weiteren Beispiel kann der Regulator entscheiden, dass nur eine ausgewählte Gruppe von glaubwürdigen Apps Zugriff auf Daten auf den GPS-Koordinaten eines Soldaten hat. Gemäß einer Ausführungsform gibt es keine Laufzeitlogik, um zu erkennen, was sicher ist, was eine potentielle Gefahr oder eine aktuelle Gefahr ist. Dies ist in erster Linie durch den Regulator in den Richtlinien vorbestimmt, die bei Schritt 404 zuvor erzeugt wurden. Bei einer weiteren Ausführungsform können einige Laufzeitlogiken vorhanden sein. Beispielsweise kann eine App versuchen, teure SMS Textnachrichten zu versenden. Das App-Kontrollprogramm kann dies erkennen und die App davon abhalten, mehr als eine bestimmte Anzahl von Textnachrichten zu versenden, zum Beispiel kann sie sie auf die Übertragung einer Nachricht begrenzen. Die Erweiterung kann etwas Neues hinzufügen, wie beispielsweise ein Passworterfordernis. Bei einem weiteren Beispiel kann die abgesicherte App, falls die Anfrage auf sichere Daten auf dem mobilen Gerätespeicher erfolgt, aktuell die Daten auf einen Speicherbereich in der Cloud oder im Internet, (das heißt außerhalb des Gerätes) sichern. Bei einem anderen Beispiel können die Daten bezüglich einer Anfrage verschlüsselt werden.
-
Bei Schritt 510 kann die abgesicherte App ermitteln, dass die Anfrage eine aktuelle Bedrohung ist und auf eine strengere Art als bei Schritt 508 behandelt werden sollte. Beispielsweise kann entschieden werden, dass basierend auf den Richtlinien für eine App, falls auf eine Kamera auf dem Gerät zugegriffen wird, während man sich in einem sicheren Gebäude (zum Beispiel im Pentagon) befindet, die App unmittelbar beendet wird. Die Anfrage lediglich zu verbessern, kann in diesem Fall nicht ausreichend sein. Bei Schritt 510 kann der Anfrage nicht erlaubt sein zu dem Betriebssystem oder anderen Komponenten des Gerätes weiter zu gelangen. Jedoch wird bei einer Ausführungsform eine Antwort an die App zurückgegeben, aber diese Antwort ist absichtlich nicht akkurat oder korrekt. Es ist im Wesentlichen eine verschleierte Antwort. Beispielsweise kann es eine GPS-Position sein, die nicht die gegenwärtige physikalische Position des Gerätes darstellt (zum Beispiel das Gerät ist in Kalifornien, aber die GPS-Position, die an die App zurückgegeben wird, ist eine Position in Nebraska). Dies kann von Vorteil sein, wenn die Apps durch Kinder benutzt werden. Andere Beispiele können die Rückgabe von schlechten oder entstellten Datenergebnissen sein, falls eine von einer App die nur innerhalb einer beschränkten Umgebung (zum Beispiel einen sicheren Bürobereich) laufen soll, erkannt wird außerhalb dieses Bereichs (zum Beispiel zu Hause) zu laufen. Bei diesem Beispiel wird die App partiell kaputtgemacht, so dass die App nur auf unklassifizierte Daten zugreifen kann und wobei klassifizierte Informationen ungültig gemacht werden. Bei einem anderen Beispiel, kann wenn der Benutzer versucht, sensitive Daten von einer klassifizierten App auf eine nicht klassifizierte App zu verschieben oder zu kopieren, das App-Kontrollprogramm die Kopie der Daten verändern, die an den Müll weitergegeben werden oder im Wesentlichen sinnlos gemacht werden. Nachdem einer der Schritte 506, 508 oder 510 abgeschlossen ist, führt die Sicherheitsgepackte App die Ausführung auf dem Mobilgerät bei Schritt 514 fort.
-
Bei Schritt 512 hat die Sicherheitsschicht um die App ermittelt, dass die Anfrage, die durch die App durchgeführt wird, oder dass das Ausführungsverhalten der App im Allgemeinen ein zu hohes Sicherheitsbedrohungslevel für das Mobilgerät darstellt. Bei diesem extremen Fall entscheidet die Sicherheitsschicht die Ausführung der App zu beenden und/oder die App zu löschen. Beispielsweise kann die App zu viele Ressourcen auf dem Telefon benutzen, wie beispielsweise die Bandbreite oder sie führt zu viele Hochrisikoanfragen an das Betriebssystem aus, bei Offenlegung des Mobilgeräts. In diesem Fall kann die App einfach von dem Telefon gelöscht werden oder die App kann beendet werden. Der Benutzer kann dann nicht in der Lage sein, diese neue auszuführen oder neu zu installieren. Beispielsweise kann ein Arbeitnehmer diese App nicht wieder auf einem Unternehmenstelefon installieren, da sie sensitive Unternehmensdaten freigegeben hat. Oder es kann ermittelt werden, dass eine App Geheimdaten auf dem Telefon sammelt oder ein Schadprogramm installiert.
-
6 ist ein Systemarchitektur-Diagramm des App-Sicherheitskontrollsystems gemäß einer Ausführungsform. Eine Triggerverwaltungskomponente 602 handhabt zwei Vorgänge, einen für die Erzeugung einer neuen Richtlinie 604 und einen weiteren für die Aktualisierung von Richtlinienparametern 606. Solche Ereignisse können durch verschiedene Systeme getriggert werden. Beispielsweise kann ein Konsolenadministrator oder Regulator eine neue Richtlinie auf allen Geräten anwenden (eine manuelle Operation). Oder eine Netzwerküberwachungsanwendung, kann, nach der Erkennung von verdächtigem Verkehr, der von einem Gerät (oder App) stammt, eine neue Richtlinie forcieren, die einen Benutzer/Gerät/App davor schützen würde, auf Netzwerkressourcen zuzugreifen (ein Beispiel für einen automatisierten Vorgang). Die verschiedenen Systeme oder Einheiten, die die Befugnis haben Richtlinien zu ändern oder zu aktualisieren, tun dies über den Triggermanager 602.
-
Eine neue Richtlinienausgabe 604 ist Eingabe für eine Richtliniendefinitionsdatei 608, die zur Laufzeit erzeugt werden kann und verschiedene Typen von Code und Erweiterungen beinhalten kann, beispielsweise spezifisch für den App-Kontrollserviceprovider oder für die App/Benutzer/Gerät, an den sich die Richtlinie wendet. Die Richtliniendefinitionsdatei 608 ist Eingabe für einen Richtliniencompiler 610, welcher zwei Ausgaben hat. Eine Ausgabe ist eine Wrapper-Definitionsdatei 612. Diese Datei ist Eingabe an eine App-Wrapperkomponente 614. Die App-Wrapperkomponente 614 ist verantwortlich für die Erzeugung gesicherter Apps durch Einbringen von benutzerspezifiziertem Binärcode (Nativ- oder Bytecode) in eine App, die direkt, beispielsweise von einem App-Store heruntergeladen wurde. Oder die App kann eine App sein, die der Benutzer auf sein Gerät heruntergeladen hat und dann auf einen App-Kontrollserver hochgeladen hat.
-
Die App-Wrapperkomponente 614 kann drei Eingaben haben: Apps von einem oder mehreren App-Stores 616, zertifizierte Schlüsselverwaltungsdaten von der Identitätsverwaltungskomponente 618, und gestärkten (bzw. hardened) Komponenten 620. Schlüsselverwaltungsdaten werden verwendet, um die Identitäten der Benutzer, des Geräts und der App zu verknüpfen und um sicherzugehen, dass jeder Vorgang, der Teil der Richtlinienkontrolle ist, mit einem bestimmten Nutzer/Gerät/App verknüpft werden kann. Dies stellt auch sicher, dass eine umhüllte Anwendung nur auf einem bestimmten Gerät laufen kann, um eine schädigende App daran zu hindern, Richtlinien und abgesicherte Komponenten (zum Beispiel „Gerätesicherheitsframework”) zu umgehen. Die Ausgabe des App-Wrappers 614 ist eine umhüllte App 622, welche über den Gerätecontroller 626 heruntergeladen oder auf dem Mobilgerät 624 installiert wird. Die Verantwortungen des Gerätecontrollers 626 beinhaltet: Lade App von dem App-Wrapper herunter; stelle sicher, dass Apps, die auf den Geräten laufen, entsprechend umhüllte Apps sind (zum Beispiel eine App, die für den Benutzer 1 umhüllt ist, sollte nicht auf einem Gerät für Benutzer 2 installiert werden oder laufen); berichte Liste/Version von installierten Anwendungen, um der Verwaltungskonsole zu erlauben, Richtlinien für jedes Gerät/Benutzeranwendung zu steuern; und lade Richtlinienparameter herunter, wenn erforderlich. Die umhüllte App 622 befindet sich auf dem Gerät 624, gekoppelt mit Richtlinienparametern 628.
-
Zurückkehrend zu dem Richtliniencompiler 610, ist die andere Ausgabe ein Laufzeitrichtliniendefinitionsfile 630. Der File ist Eingabe für einen Laufzeitrichtliniencompiler 632, welcher auch Richtlinienparameter 606 (spezifiziert durch die Verwaltungskonsole oder andere Subsysteme) als Eingabe akzeptiert. Die Ausgabe des Compilers 632 ist ein Gerätelaufzeitrichtlinienfile 634. Der File 634 wird auf das Gerät 624 heruntergeladen, wie als Richtlinienparameter 628 gezeigt, und wird zur Anpassung der Richtlinien, die auf die umhüllte App 622 angewandt werden, verwendet.
-
Im Folgenden sind sind verschiedene Anwendungsfälle und Möglichkeiten des App-Kontrollsicherheitsprogramms der vorliegenden Erfindung beschrieben. Ein Anwendungsfall beinhaltet die Auftrennung des Bereichs des Arbeitslebens und des persönlichen Lebens auf einem Mobiltelefon. Es gibt Apps für die persönliche Benutzung des Benutzers und Apps, die der Arbeitgeber des Benutzers (oder ein Geschäftspartner des Arbeitgebers) bereitgestellt hat und die Apps laufen auf dem gleichen Telefon, welches oft das persönliche Telefon des Benutzers ist. Der Regulator, der die Sicherheit der Apps ermittelt, die auf dem Telefon des Benutzers zu sichern sind, kann Kopier/Verschiebevorgänge (bzw. copy/gaste) zwischen Apps (wie beispielsweise Email-Apps) blockieren. Der Regulator kann Richtlinien für die arbeitsbezogenen Apps festlegen, die ein selektives Bereinigen von Apps und den dazugehörigen Dateien durchführen. Positionsbezogene Benutzerrichtlinien können auch steuern, wo bestimmte Apps ausgeführt werden können. Beispiele für Schutzlevel aufgrund von Schadprogrammen verweigern den Zugang zu Kontakten, verweigern die Übertragen von SMS ohne Zustimmung und dergleichen.
-
Ein weiteres Beispiel für einen Benutzungsfall ist die App-Kontrolle. Unter Benutzung der vorliegenden Erfindung kann das White- und Black-Listing von Apps, als auch die vollständige Entfernung von Apps entsprechend den Richtlinien implementiert sein, die durch den Regulator gesetzt wurden. Eine App kann „sandboxed” sein (d. h. abgeschirmt sein), um andere Apps, Software und Hardware des Geräts zu schützen. Andere Fähigkeiten beinhalten das identitätsbezogene Kontrollieren von Apps oder von Diensten und eine sehr detailierte Kontrolle über das App-Verhalten. Die Identifizierung durch Trojaner ist ein weiterer Benutzungsfall, der mit dem App-Sicherheitsprogramm implementiert sein kann. Beispielsweise kann jede App und der Inhalt verschlüsselt sein, um zu verhindern, dass Schurken-Apps Zugang erhalten und vertrauliche Daten von dem Telefon stehlen. Das Sicherheitsprogramm kann auch in der Lage sein, anormales Systemanrufverhalten von einer App zu identifizieren, um schädliche Trojaner-Apps zu identifizieren, die außerhalb ihrer bekannten Intention handeln.
-
Ein weiterer Anwendungsfall ist das Sichern (bzw. Back-Up) und Wiederherstellen von App-Daten, bei denen IT-Sicherheitsadministratoren und Regulatoren eine Datenüberprüfungskontrolle haben und App- und Geräteinhalt-Migration über Sicherungs- und Wiederherstellungsvorgänge implementieren können. Ein weiterer Benutzungsfall ist die Überwachung von Netzwerkverkehr. Die App auf dem Mobilgerät kann unter die Sichtbarkeit von existierenden Unternehmens-IDS/IPS/Web-Filter-Infrastrukturen gebracht werden, um eine Inspektion und Kontrolle der App-Kommunikation zu erlauben. Das App-Sicherheitsprogramm kann auch mit DNS-Diensten Dritter integriert werden, wie beispielsweise Symantec's DNS-Service zur Identifizierung von Schadprogrammen. Die ganze App-Kommunikation kann verschlüsselt sein, inklusive der Kommunikation bei dem Mobilfunk-Serviceprovider. Andere Benutzungsfälle beinhalten den Fortbestand der Sitzung, Benutzerprivatsphäre (z. B. GPS Verschleierung, Implementierung sicherer DNSs), und Abfangen von Zahlungs-/Transaktionsnachrichten von dem Mobilgerät (d. h., agieren in der Mitte von mobilen Handelsströmen).
-
Bei einer Ausführungsform wird der App-Sicherheitsservice von einem dritten Service-Provider zur Verfügung gestellt, z. B. um Apps herzustellen, die von Endbenutzern oder Einzelpersonen (d. h., Benutzern, die nicht mit einem Arbeitgeber oder Unternehmen verbunden sind) herzustellen. Beispielsweise möchten Eltern das GPS des Telefons eine Kindes verschleiern, da die Eltern nicht wollen, dass eine soziale Netzwerkseite, wie z. B. Facebook weiß, wo sich das Kind befindet, im Wesentlichen das Ausschalten von GPS. Bei einer anderen Ausführungsform kann ein App-Store, der von einem Mobilfunk-Betreiber (z. B. Verizon, AT&T) betrieben ist, eine gesicherte App für einen Extrabetrag oder mit Aufpreis anbieten. Ein Benutzer des Providers kann durch Zahlung eines Extrabetrags anstelle der ungesicherten Version die abgesicherte App von dem Marktplatz oder Online-Store herunterladen. Bei einer anderen Ausführungsform kann ein Unternehmen seinen eigenen App-Store für seine Mitarbeiter, Partner und dergleichen haben, bei dem Benutzer nur abgesicherte Versionen der Apps herunterladen können (welche als „harte” Apps bezeichnet werden können). Diese Apps haben viele der zuvor beschriebenen Sicherheitsmerkmale, wie durch einen Regulator (Sicherheitsadministrator) bei dem Unternehmen definiert, wie z. B. das Blockieren von Kopieren und Einfügen von Email- oder Unternehmensdaten, das Töten einer App auf dem Telefon des Benutzers, falls der Benutzer die Firma verlässt, und so weiter. Der DNS eines Mobilfunkbetreibers kann typischerweise auf jede Seite zugreifen, aber das App-Sicherheitsprogramm kann den Browser eines mobilen Geräts blockieren, sodass es nur auf einen sicheren DNS (z. B. Symantec's DNS) zugreifen kann, von dem aus nur auf sichere Websites zugegriffen werden kann. Bei einer anderen Ausführungsform kann der App-Sicherheitsprogramm-Provider mit dem Mobilgerätehersteller arbeiten, um das App-Sicherheitsprogramm oder die Funktionalität in die Hardware- oder die Software-Operationen des Gerätes zu integrieren. Bei dieser weiter unten beschriebenen Ausführungsform, kann ein Benutzer eine ungesicherte App herunterladen und kann diese selbst auf dem Telefon oder Gerät sicher machen, bevor sie ausgeführt wird, und muss nicht auf einen Service Dritter zugreifen, um die App abzusichern oder um sicherzugehen, dass die App abgesichert ist, bevor sie auf das Gerät heruntergeladen wird.
-
Wie bei verschiedenen oberhalb beschrieben Ausführungsformen ersichtlich ist, geht die Sicherheit des Mobilgeräts über das Gerät selbst hinaus und wird direkt auf die Apps angewandt, die auf das Gerät heruntergeladen werden. Unternehmen und andere Einheiten sind in der Lage, großzügig Vorteile aus Apps gewinnen, ohne über Sicherheitsrisiken, wie Datenlecks oder Schadprogramminfektionen auf dem Unternehmens-IT-System der Firma, besorgt zu sein. Firmen können die Herrschaft über ihre Unternehmensdaten aufrechterhalten.
-
Bei einem weiteren Aspekt der Gerätesicherheit und App-Ausführung lädt ein Benutzer eine ungesicherte App herunter und lässt sie mit einer aufgezwungenen Richtlinie durch eine vorinstallierte Maschine auf dem Gerät ausführen. Auf diese Art ist die App grundsätzlich auf dem Gerät abgesichert (Verwendung einer Richtlinie auf dem Gerät), wonach die zwangsgesicherte App ausgeführt werden kann. Bei diesem Aspekt der Gerätesicherheit und App-Ausführung kann ein dritter App-Sicherheits-Provider seine Dienste mit bestehenden Diensten (z. B. Firmware), die von dem Gerätehersteller bereitgestellt ist, integrieren oder vorher bereitstellen. Als solche kann diese Ausführungsform als eine zuvor eingesetzte (pre-deployed) Ausführungsform bezeichnet werden. Das heißt, dass der Provider und der Gerätehersteller zusammenarbeiten, sodass das Gerät (hergestellt durch den Hersteller) Software und/oder Firmware enthält, die mit dem Gerätebetriebssystem interagiert oder kommuniziert und in dem Gerät integriert ist. Bei dieser Ausführungsform kann der Gerätehersteller potenzielle Benutzer informieren (z. B. bewerben), dass das Gerät wie beispielsweise ein Smartphone sicherer bezüglich der Ausführung von Apps ist, als das Gerät eines Mitbewerbers. Der Benutzer lädt weiterhin Apps in einer gewphnten oder herkömmlichen Art herunter, bei der die Apps wahrscheinlich ungesichert sind (das heißt unumhüllt), und wenn die App auf dem Gerät ausgeführt wird, ist sie im Wesentlichen abgesichert und es ist viel weniger wahrscheinlich, dass sie auf dem Gerät einen Schaden verursacht.
-
Bezüglich der Komponenten und Module der Ausführungsformen, die zuvor beschrieben wurden (d. h. nachentwickelte (post-deployment) Ausführungsformen), macht sich dieser Aspekt der Erfindung nutzbar, was mit einem Äquivalent zu dem Richtlinienmanager 202 beschrieben sein kann. Das heißt, die Funktionen des Richtlinienmanagers 202 sind unter Verwendung anderer Module und Techniken in den vorinstallierten Ausführungsformen implementiert. Bei einer Ausführungsform kann der Richtlinien-Wrapper 208 wie zuvor beschrieben, nicht auf dem Gerät benötigt werden, da die Sicherheitsdurchsetzung auf dem Gerät durch Interpretieren oder Kompilieren einer Richtlinie durch eine Durchsetzungsschicht erfolgt. Bei einigen Geräten wie beispielsweise Mobilgeräten gibt es häufig einen Typ-2-Hypervisor oder eine App-„Sandbox”, die über der laufenden Software arbeitet. Dieser herkömmliche Hypervisor oder Sandbox erlaubt einer App, abzulaufen oder nicht. Es erlaubt bezüglich der App-Sicherheit eine Art limitierte binäre Funktionalität. Bezüglich bestimmter Aspekte der vorliegenden Erfindung, wie weiter unten beschrieben, arbeitet ein weiterer Typ von Hypervisor oberhalb des herkömmlichen Typ-2-Hypervisors, bei der eher eine Logik ermöglichende Funktionalität durchgeführt wird als eine „Erlauben- oder -nicht-Erlauben”-Typ Funktionalität.
-
Normalerweise arbeiten Apps durch Interaktion mit einer Sandbox-Schicht über dem Betriebssystem des Geräts. Dieser Dienst dient dazu, sicherzugehen, dass die Apps nicht während der Ausführung miteinander interferieren. Bei iOS benutzen die Apps gemeinsame Objektfiles und die Ausführung erfolgt durch SWI-Anweisungen. Die Sandbox ist Teil des iOS Betriebssystems.
-
Wie allgemein bekannt ist, können eine oder mehrere Apps in der Sandbox (oder ähnlichen virtuellen Umgebungen) auf dem Gerät zu jeder beliebigen Zeit ausgeführt werden. Bei einer Ausführungsform der vorliegenden Erfindung ist eine App-Richtliniendurchsetzungsschicht oder -Maschine zwischen den Apps und der Sandbox implementiert. 7 ist ein Blockdiagramm, das eine Struktur für eine App-Sicherheit auf einem Gerät gemäß einer Ausführungsform der vorliegenden Erfindung zeigt. Diese Struktur hat Module und Komponenten, die auf dem Gerät vorhanden sind, z. B. ein Smartphone, Tablet oder Fernseher. Gezeigt sind mehrere Apps, wobei jede Box 702a, 704a, 706a... die Software für jede App repräsentiert, die auf dem internen Speicher des Geräts (nicht dargestellt) vorhanden sind. Zugefügt zu jeder App ist eine Richtlinie 702b, 704b, 706b.... Wie oben bemerkt, können einige Apps keine Richtlinie haben. Jedoch hat der Richtlinienmanager 202 in den meisten Fällen seine Funktion ausgeführt, das heißt Erzeugen und Verwalten von Richtlinien für die Apps des Benutzers. Da die Richtlinien auf dem Gerät sind (oder sie werden auf das Gerät mit der App heruntergeladen), sind die Funktionen des Richtlinienmanager erledigt. Die Richtlinien für jede App oder generische Richtlinien für den Benutzer befinden sich bereits auf dem Gerät. Jedoch, wie weiter unten beschrieben, gibt es einen Prozess um sicherzugehen, dass die App eine zugeordnete Richtlinie hat, bevor es ihr erlaubt ist, auszuführen oder Systemaufrufe durchzuführen. Die App-Richtliniendurchsetzungsschicht 706 enthält eine Logik, um zu ermitteln, was jedes Mal getan werden muss, wenn eine Systemanfrage durch eine App erfolgt. Wenn eine App durch den Benutzer auf das Gerät heruntergeladen ist, muss die App nicht bereits zuvor umhüllt oder abgesichert sein; sie kann unumhüllt sein, wie die Mehrheit momentan ist. Es ist auch möglich, dass eine abgesicherte oder umhüllte App heruntergeladen werden kann und die gleichen Konzepte und Methoden wie weiter unten beschrieben können erfolgen.
-
Wie bemerkt, ist die App-Richtliniendurchsetzungsschicht 706 eine Softwaremaschine, die sich auf dem Gerät befindet, sie kann aber auch durch einen App-Steuerungsserviceprovider geliefert und erzeugt werden und auf dem Gerät durch den Gerätehersteller integriert sein. Die durch die Schicht 706 durchgeführte Logik ist in 8 beschrieben. Das Ausführen unter der Schicht 706 ist eine konventionelle Typ-2-Sandbox 708 und die Betriebssystem-Software 710.
-
Die Durchsetzungsschicht 706 ermittelt, wie eine App sich verhalten soll, wenn sie abläuft. Sie untersucht die Richtlinien, um zu ermitteln, welche Aktionen durchgeführt werden sollen, wenn sie abläuft. Die Durchsetzungsschicht 706 kann überhaupt kein Wissen aufweisen, wie eine App sich verhalten soll bezüglich der Sicherheit auf dem Gerät. Das heißt, die Schicht 706 weiß nicht, was der App erlaubt ist oder verboten ist auf dem Gerät zu tun. Bei einer Ausführungsform ist der einzige Weg, wie sie zu der Erkenntnis gelangen kann, die Ausführung der Richtlinien, die mit der App verbunden sind. Bei einer Ausführungsform interpretiert die Schicht 706 die Richtlinie, die Computercode beinhaltet, wenn die App einen Systemaufruf oder eine Anfrage durchführt. Durch diese Interpretation ermittelt die Schicht 706, wie die App auf dem Gerät ablaufen oder verhalten kann. Bei einer Ausführungsform, nachdem die Richtlinie durch die Schicht oder Maschine 706 interpretiert wurde, kann eine der vier Aktionen durchgeführt werden. Diese vier Aktionen sind die Gleichen die bereits zuvor beschrieben sind. Diese sind wiederum in 8 in dem Zusammenhang des Sicherheitsumhüllens einer App auf dem Gerät (Voreinsatz(pre-deployment)-Ausführungsform) gezeigt.
-
8 ist ein Flussdiagramm eines Verfahrens zur Anwendung einer Sicherheitsrichtlinie an einer App vor der Ausführung auf einem Gerät gemäß einer Ausführungsform. Bei Schritt 802 führt eine App, die bereits existiert, einen Systemaufruf an das Betriebssystem des Geräts durch. Bei einer Ausführungsform erfolgen die Schritte der Anwendung der Richtlinie und Ermitteln, welche Sicherheitshandlungen durchzuführen sind, nur, nachdem die App einen aktuellen Aufruf an das Gerätebetriebssystem durchführt. Bei Schritt 804 überprüft die Durchsetzungsschicht 706, ob es eine Richtlinie für die App gibt, die abläuft. Dies kann mit Hilfe von dem Richtlinienmanager erfolgen. Ein Beispiel für eine Richtlinie ist weiter unten bereitgestellt. Falls es keine Richtlinie für die App gibt, wird eine Standardrichtlinie für die App oder den Benutzer von dem Gerätespeicher erhalten. Eine Standardrichtlinie wird durch den Benutzer oder den Gerätehersteller gesetzt.
-
Falls es eine Richtlinie gibt, geht die Steuerung zu Schritt 808, bei dem die Richtlinie an die App auf dem Gerät angewendet wird. Bei der beschriebenen Ausführungsform wird die Richtlinie durch die Maschine 706 interpretiert. Sobald sie angewendet ist, weiß die Durchsetzungsmaschine 706, wie sich die App verhalten kann, das heißt, sie weiß, was sie der App erlauben kann zu tun. Bei einer weiteren Ausführungsform kann die Durchsetzungsschicht 706 anstelle der Interpretation die Richtlinien kompilieren. Beispielsweise kann sie einen „Just-in-time”-Kompilierungsvorgang durchführen, erzeugt Code auf den Punkt, für die App, wo der Code einmalig für die App ist. Wie in der Technik bekannt ist, ist das JIT-Kompilieren üblicherweise effizienter als eine Interpretierung und kann typischerweise nur erfolgen, falls sie durch das Betriebssystem erlaubt ist. Typischerweise ist das dynamische Laden von Code nur privilegierten Betriebssystemkomponenten erlaubt. Bei einer anderen Ausführungsform kann die Sandbox 710 (Typ-2-Hypervisor) auch bei Kollabieren der Sandbox 708 in das Betriebssystem 710 geschützt werden.
-
Nach Schritt 808 wendet die Durchsetzungsschicht 706 ihre Logik an und ermittelt, welche Aktion bzgl. des Verhaltens der App durchzuführen ist oder welche Aktion die App bei Schritt 810 durchführen kann. Der Aufruf kann keine Bedrohung für das Gerät sein und kann einfach zu dem Betriebssystem wie bei Schritt 814 gezeigt weitergereicht werden. Von dort geht die Steuerung weiter zu Schritt 820, wo die App mit der Ausführung unter Benutzung des App-Richtliniendurchsetzungsschicht 706 weiter fortfährt. Falls die Durchsetzungsschicht 706 erkennt, dass die App eine Anfrage durchführt, die eine Sicherheitsbedrohung für das Gerät darstellt, kann die Durchsetzungsschicht die aktuelle Anfrage verbessern oder modifizieren, bevor sie an das Betriebssystem oder andere Software- oder Hardwarekomponenten in dem Telefon, wie bei Schritt 816 gezeigt, weitergegeben wird. Nachdem die Anfrage modifiziert ist, ist es erlaubt, zu dem Betriebssystem weitergegeben zu werden. Die Steuerung geht weiter zu Schritt 814 (und dann weiter zu Schritt 820). Die Durchsetzungsschicht 706 kann ermitteln, ob der aktuelle Aufruf durch die App eine aktuelle Bedrohung ist und auf eine strengere Art behandelt werden sollte, als bei Schritt 816. Beispielsweise kann es der Anfrage nicht erlaubt sein, zu dem Betriebssystem oder jeglicher anderen Komponente auf dem Gerät weitergegeben zu werden. Jedoch wird bei einer Ausführungsform, obwohl die Anfrage geblockt sein kann, eine Antwort dennoch an die App zurückgegeben, aber diese Antwort ist absichtlich nicht akkurat oder korrekt wie bei Schritt 818 gezeigt. Es ist eine verschleierte oder absichtlich falsch zu interpretierende Antwort. Falls die Durchsetzungsschicht 706 ermittelt hat, dass die Anfrage, die durch die App erfolgt ist oder dass die das App-Ausführungsverhalten im Allgemeinen ein zu hohes Sicherheitsrisiko für das Gerät darstellt, wird die App durch die Durchsetzungsschicht 706 bei Schritt 822 beendet oder gelöscht. Das Verfahren endet nach Schritt 822 (d. h. die Steuerung geht nicht zu Schritt 820). Die Steuerung geht dann zu Schritt 820. Von Schritt 820 geht die Steuerung zurück zu Schritt 810, wo die Durchsetzungsschicht 706 ermittelt, welche Aktion durchzuführen ist.
-
Diese Ausführungsform kann als Containeransatz (bzw. container approach) bezeichnet werden, bei dem sich ein Container um die App hüllt. Hier ist der Container Teil der Sandbox 708. Bei anderen momentan in Benutzung befindlichen Systemen gibt es im Wesentlichen einen großen Container und alle Apps müssen programmiert sein, einzeln im Container (z. B. Good Tech) ausgeführt zu werden. Um außerhalb des Containers ausgeführt zu werden, muss die App den Container verlassen. Bei der beschriebenen Ausführungsform der vorliegenden Erfindung können zwei verschiedene Apps, eine abgesicherte und eine andere ungesicherte, in der Durchführungsschicht 706 zur gleichen Zeit laufen.
-
Wie bemerkt können, wenn eine App heruntergeladen ist, eine oder mehrere Richtlinien zusammen mit der App heruntergeladen werden. Ein Aufruf oder eine Anfrage erfolgt an einen Richtlinienmanager um nach Richtliniendaten zu suchen, die für die jeweilige App benötigt werden. Bei der beschriebenen Ausführungsform ist die App nicht verändert.
-
Wie bei den verschiedenen Ausführungsformen klar ist, einem Voreinsatz- (bzw. pre-deployment) Szenario und den anderen Ausführungsformen, sind die App-Richtlinien ein Schlüsselelement bei der Gewährleistung der Sicherheit auf dem Gerät. Ein Beispiel für eine Richtlinie kann sein, dass, falls zwei Apps von dem gleichen Autor stammen und daher den gleichen privaten Schlüssel haben und es erscheint, dass beide Apps zur gleichen Zeit ausgeführt werden, bestimmte Aktionen erfolgen, die verhindern, dass die beiden Apps miteinander kommunizieren oder Informationen austauschen. Eine App kann ein Kontaktmanager sein und die andere App kann eine SMS-App sein. Da beide die gleiche Signatur haben, können die beiden Apps einander im Wesentlichen sehen und unerlaubt zusammenwirken. Es ist möglich, dass eine oder mehrere Apps von dem gleichen Autor, die zur gleichen Zeit ausgeführt werden, Daten austauschen und Schaden für das Gerät verursachen, auch wenn jede App gutartig ist, wenn sie separat ausgeführt wird. Die Richtlinie kann Apps, die mit dem gleichen privaten Schlüssel signiert sind, davon abhalten, Daten in der Sandbox 708 auszutauschen, welche unterhalb der Durchsetzungsschicht 706 arbeitet. In dieser Hinsicht verbessert die beschriebene Ausführungsform der vorliegenden Erfindung die Ausführungen der Sandbox 708. Beispielsweise kann die vorliegende Erfindung, die Erfordernisse für binäre Operationen wie blacklisting oder whitelisting von Apps und dergleichen eliminieren oder reduzieren.
-
Die 9a und 9b zeigen ein Computersystem 900, das geeignet ist für die Implementierung von Ausführungsformen der vorliegenden Erfindung. 9a zeigt eine mögliche physikalische Form des Computersystems. Selbstverständlich kann das Computersystem viele verschiedene physikalische Formen aufweisen, inklusive einer integrierten Schaltung, einer Platine, eines kleinen Handgeräts (wie z. B. ein Mobiltelefon, Handgerät oder PDA), eines Heimcomputers oder eines Supercomputers. Das Computersystem 900 beinhaltet einen Monitor 902, ein Display 904, ein Gehäuse 906, ein Laufwerk 908, eine Tastatur 910 und eine Maus 912. Das Laufwerk ist ein computerlesbares Medium, das zum Transfer von Daten von und zum Computersystem 900 verwendet wird.
-
9b ist ein Beispiel für ein Blockdiagram für das Computersystem 900. Angeschlossen an dem Systembus 920 sind eine große Vielzahl von Subsystemen. Prozessor(en) 922 (auch bezeichnet als zentrale Recheneinheiten oder CPUs) sind an Speichergeräte, die den Speicher 924 enthalten, angeschlossen. Der Speicher 924 beinhaltet einen Zufallszugriffsspeicher (RAM) und Nur-Lesespeicher (ROM). Wie aus der Technik bekannt ist, agiert der ROM um Daten und Instruktionen uni-direktional zu der CPU zu transferieren und der RAM wird typischerweise zum Transfer von Daten und Instruktionen auf eine bidirektionale Art verwendet. Beide dieser Arten von Speicher können jede der weiter unten beschriebenen computerlesbaren Medien beinhalten. Eine Festplatte 926 ist auch bidirektional an die CPU 922 angeschlossen; sie stellt zusätzliche Datenspeicherkapazität zur Verfügung und kann auch jegliche der weiter unten beschriebenen computerlesbaren Medien beinhalten. Die Festplatte 926 kann zur Speicherung von Programmen, Daten und dergleichen verwendet werden und ist typischerweise ein sekundäres Speichermedium (wie z. B. eine Harddisk, die langsamer ist als Primärspeicher). Es wäre von Vorteil, dass die Informationen, die auf der Festplatte 926 gewahrt sind, können bei entsprechenden Fällen auf Standard Art und Weise als virtueller Speicher in dem Speicher 924 beinhaltet sein. Die Wechselplatte 914 kann die Form von jede der weiter unten beschrieben computerlesbaren Medien annehmen.
-
Die CPU 922 ist auch an eine Vielzahl von Eingabe-/Ausgabegeräten, wie beispielsweise ein Display 904, eine Tastatur 910, eine Maus 912 und Lautsprecher 930 gekoppelt. Im Allgemeinen kann ein Eingabe-/Ausgabegerät jedes der Folgenden sein: Videodisplays, Trackballs, Mäuse; Tastaturen, Mikrofone, berührungssensitive Displays, Übertragungsdatenleser, Magnetisch- oder Papierbandleser, Tablets, Eingabestifte, Sprach- oder Handschriftenerkenner, biometrische Leser oder andere Computer. Die CPU 922 kann optional an einen anderen Computer oder ein Telekommunikationsnetzwerk unter Verwendung der Netzwerkschnittstelle 940 gekoppelt sein. Über solch eine Netzwerkschnittstelle ist vorgesehen, dass die CPU Informationen im Rahmen der Durchführung der zuvor beschriebenen Verfahrensschnitte von dem Netzwerk empfangen kann oder Informationen an das Netzwerk ausgeben kann. Des Weiteren können Ausführungsformen des Verfahrens der vorliegenden Erfindung ausschließlich durch die CPU 922 ausgeführt werden oder können über ein Netzwerk, wie beispielsweise dem Internet in Verbindung mit einer Remote CPU ausgeführt werden, die einen Teil des Verfahrens teilt.
-
Obwohl illustrative Ausführungsformen und Anwendungen dieser Erfindung hierin gezeigt und beschrieben sind, sind viele Variationen und Modifikationen möglich, welche das Konzept, den Umfang und Erfindungsgedanken beibehalten, und diese Abwandlungen sind für den Fachmann nach sorgfältigem Studium dieser Anwendung klar. Entsprechend sind die hierin beschriebenen Ausführungsformen als veranschaulichend anzusehen und nicht beschränkend, und die Erfindung ist nicht beschränkt auf die hierin angegebenen Details, sondern kann innerhalb des Erfindungsgedankens und Abwandlungen der angehängten Ansprüche modifiziert werden.
