Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR ASSESSING AND CONTAINING RISKS FROM SMARTPHONE APPLICATIONS
Document Type and Number:
WIPO Patent Application WO/2013/067989
Kind Code:
A2
Abstract:
The inventive method described here provides a technical improvement for mobile radio customers for protecting against malicious applications (apps) which have the potential to transmit personal data belonging to the customer to third parties without this being noticed by the customer. Further dangers arise from apps which secretly obtain control over a microphone and/or camera and/or communication channels such as a mobile network or WLAN and are thus able to spy out the environment of the customer or to send expensive premium SMSs at the expense of the customer. The method provides protection against this by virtue of warnings to the customer, with detailed breakdowns of potential risks and risks which have already occurred. Other variants of the method which are demonstrated here provide structures which are imposed on the applications, as a result of which it is not possible to manipulate designation addresses or to feign addresses which are allegedly used. This also ensures that incorruptible customer input is transferred, i.e. what the customer sees or inputs is also transferred and used in that form without corruption.

Inventors:
LINZ JOACHIM (DE)
SCHMIDT ROLAND (CA)
Application Number:
DE2012/001046
Publication Date:
May 16, 2013
Filing Date:
October 27, 2012
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
LINZ JOACHIM (DE)
International Classes:
G06F21/51; G06F21/53
Foreign References:
EP1971102A12008-09-17
Other References:
None
Attorney, Agent or Firm:
LINZ, JOACHIM (DE)
Download PDF:
Claims:
Patentansprüche

Verfahren zum Bewerten und Eindämmen von Risiken durch Smart-Phone-Applikationen. 1. Verfahren zum Identifizieren von Applikationen, die auf mobilen Endgeräten installiert sind oder installiert werden oder gerade dorthin geladen werden, derart dass die Berechtigungen einer jeden dieser Applikationen verfahrensgemäß durch eine auf dem mobilen Endgerät installierten CheckApp Einrichtung überprüft werden und dem Nutzer des Endgerätes detaillierter dargelegt werden als dies während des Installationsablauf der Applikation durch etablierte Abläufe unter dem Zusammenwirkens von Operating-System des mobilen Endgerätes und einem Market-Place von dem die Applikationen runtergeladen werden oder ähnlichen Einrichtungen gegenüber dem Nutzer erfolgt, und anschließend die Applikation weiter beobachtet wird, derart dass geprüft wird ob sie Daten- oder Sprach- oder SMS-Verbindungen oder sonstige Kommunikationswege nach außen aufbaut oder unterhält oder anderweitig nutzt und im Falle von entsprechendem Verkehr dieser für die jeweilige Richtung gemessen wird, und zu weiteren verfahrensgemäßen Analysen diese Volumina mit Richtungsindikatoren und mit den Peeradressen der jeweiligen Verbindung gespeichert werden und im Verbund mit einer verfahrensgemäßen ServCheck Komponente, die sich auf einem verfahrensgemäßen Server befindet, mit der die CheckApp über ein Mobilnetz oder über WLAN oder sonstige Netze kommuniziert, analysiert werden, derart dass die tatsächlich genutzten und/oder die angemeldeten Zugriffsrechte einem verfahrensgemäßen

Beurteilungsprozess zugeführt werden und zusätzlich die Bekanntheit und/oder die Kritikalitat der Peer-Adressen der betrachteten Applikation mit in die Gesamtbewertung und in die

Detailbewertung mit einbezogen werden, derart dass außer einem Gesamtrating auch eine detaillierte Einzelbewertung für den Nutzer sichtbar erstellt wird, derart dass sie das Kostenrisiko für den Nutzer aufzeigt, das sich aus dem Kommunikationsverhalten der betrachteten Applikation ergibt, und/oder das Risiko für das Abfließen von Daten oder persönlichen Daten zu bekannten Peeradressen oder zu unbekannten Peeradressen und mit Indikatoren für die Kritikalitat der Adressen, die auch, aber nicht ausschließlich durch die Angabe des Landes dargestellt wird, in dem sich das Ziel oder der Ziel-Server mit der betrachteten Adresse befinden, und/oder die Entwicklung des eingetretenen Risikos, derart dass die CheckApp und/oder die ServCheck optional auf früher gespeicherte Analyseergebnisse zurückgreift, derart dass damit auch eine Schläfer-Applikation verfahrensgemäß identifiziert wird, die erst nach einer bestimmten Zeit nach der Installation aktiv wird und das potentielle Risiko zeitversetzt real werden lässt.

2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die CheckApp vor und/oder während und/oder nach der Installation einer Applikation auf dem Endgerät prüft, derart dass die CheckApp den Namen und/oder die Berechtigungsdaten liest, die vom Operating-System des Endgerätes bereitgestellt werden, und entweder aus der eigenen lokalen Datenbank Kriterien für ein Rating entnimmt und/oder durch Informationsaustausch mit der ServCheck von der ServCheck

Informationen und/oder ein Rating erhält das detaillierter ist als das Berechtigungsprofil das vom Operating-System des jeweiligen Endgerätes vor oder nach der Installation zur Verfügung gestellt wird, derart dass die CheckApp dieses Rating und/oder die Erkenntnisse aus anderen Installationen der betrachteten Applikation auf anderen Endgeräten, die bei der ServCheck gespeichert und/oder verarbeitet werden und der CheckApp des aktuellen Endgerätes in der für diese Phase des Verfahrens aufbereiteten Form zur Verfügung gestellt werden und dem Nutzer angezeigt werden.

Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass eine mehrdimensionale Risikobewertung durchgeführt wird, derart dass diese Berechtigungen komponentenweise enthält und/oder zu jeweils einer der mehrdimensionalen Grüßen berechnet wird, derart dass die Zugriffsberechtigung und/oder die Zugriffsmöglichkeit und/oder erfolgter Zugriff auf folgende Daten und/oder Funktionen erfolgt, jedoch nicht ausschließlich: allgemeine persönliche Daten, und/oder Datenbereiche mit persönlichen Daten, und/oder Kalenderdaten, und/oder

Adressbuchdaten, und/oder Bilder, und/oder Videos, und/oder Dokumente, und/oder Emails, und/oder Email-Konto-Daten, und/oder Gesundheitsdaten, und/oder Passwörter zu WLAN und/oder Bankdaten und/oder E-Wallet-Daten.

Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass in die mehrdimensionale Bewertung auch die Zugänge zu Kommunikationskanälen mit einbezogen werden, derart dass die

Berechtigung und/oder die Möglichkeit und/oder die tatsächlich erfolgte Nutzung als boolsche Aussage einfließt und/oder aus einer komplexen Berechnung zu einer Gesamtgrüße oder komponentenweise in die mehrdimensionale Bewertung eingebracht wird, derart dass die folgenden, aber nicht ausschließlich diese Kommunikationskanäle zum Internet, und/oder zu Zielen in Sprachnetzen, und/oder zu Zielen in Datennetzen, und/oder zu sozialen Netzen, und/oder zu Chat-Gruppen, und/oder zu Ein-/Ausgabe-Geräten im Nah- und/oder Fernbereich des betrachteten mobilen Endgerätes, mit einbezogen werden: Mobilnetz, und/oder WLAN, und/oder Bluetooth, und/oder Near-Field-Kommunikation, und/oder Infrarotkanäle, und/oder SMS, und/oder MMS.

Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass auch Volumen- und/oder

Kostenkomponenten in die Bewertung mit einfließen, derart dass dem Nutzer das potentielle und/oder das bereits eingetretene Risiko allgemein und/oder pro Kommunikationskanal und/oder pro Ziel und/oder pro Zieladresse angezeigt wird, derart dass angezeigt wird ob Kosten für Kommunikation und/oder für Einkäufe in Market-Places und/oder E-Shops und/oder für

Klingeltöne und/oder für Premium-SMS oder Ähnlichem verursacht wurden oder verursacht werden können.

Verfahren nach Anspruch 1-5, dadurch gekennzeichnet, dass auch der Zustand des mobilen Endgerätes in die Bewertung einfließt, derart dass dem Nutzer gegenüber festgehalten wird zu welcher Zeit eine Applikation aktiv war und/oder mit was, derart dass festgehalten wird ob während der Aktivitäten der Applikation das Display des mobile Endgerätes ein- oder

ausgeschaltet war, und/oder ob die Kamera und/oder das Mikrofon und/oder andere integrierten oder an das mobile Endgerät angeschlossenen Geräte eingeschaltet waren und/oder ob sie durch die Applikation eingeschaltet wurden, und/oder ob die Applikation Kommunikationsdaten oder die Kommunikationsinhalte oder beides aufgezeichnet und/oder übertragen hat.

Verfahren nach Anspruch 2-6, dadurch gekennzeichnet, dass in der Bewertung für das potentielle Risiko berücksichtigt wird ob auf dem mobilen Endgerät Entitäten vorhanden sind, die den Zugriff auf Daten und/oder Funktionen und/oder auf Ressourcen kontrollieren, derart dass das potentielle Risiko zurückgestuft wird, entsprechend dem Grad der Kontrollmöglichkeiten oder

Verhinderungsmöglichkeiten von Missbrauch durch diese Entitäten.

8. Verfahren nach Anspruch 1-7, dadurch gekennzeichnet, dass die Informationen zu den

Erfahrungen mit einer Applikation auf einem mobilen Endgerät durch die CheckApp der

ServCheck mitgeteilt werden, derart dass auch die Operating-System-Version, und/oder die Hardware-version, und/oder die Tatsache ob Entitäten zur Zugriffsbeschränkung gegenüber Applikationen auf den Endgerät vorhanden sind und/oder deren Version und/oder deren Grad von wirksamer Kontrolle, derart dass die ServCheck diese Informationen, mit oder ohne Auswertung und/oder mit oder ohne Einbeziehung von Informationen von anderen mobilen Endgeräten, anderen mobilen Endgeräten direkt oder nach deren Anfrage zur Verfügung stellt, derart dass bei späteren Downloads und/oder Installationen der entsprechenden Applikation auf anderen mobilen Endgeräten eine möglichst frühzeitige und detaillierte Warnung an den Nutzer erfolgt, derart dass diese Warnung selbst dann erfolgt, wenn das Endgerät keine eigenen Entitäten mit der

Möglichkeit zur Analyse besitzt.

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet dass die ServCheck auch den Market-Place informiert von der aus die Applikation vertrieben wird, derart dass die Applikation möglichst frühzeitig an der weiteren Distribution gehindert wird und/oder der Designer der Applikation von der Nutzung des Market-Place für weitere Distributionen wirksam ausgeschlossen wird.

10. Eine Anordnung, dadurch gekennzeichnet, dass sie aus folgenden Elementen besteht

a) einem oder mehreren Endgeräten mit einer CheckApp oder einer oder mehreren

Anwendungen oder Entitäten mit der Funktionalität der CheckApp;

b) einem oder mehreren Servern, die mit einer oder mehreren ServCheck ausgestattet sind und/oder mit Entitäten, die mit den Funktionalitäten der ServCheck ausgestattet sind;

c) einem oder mehreren Market-Places für die Distribution von Applikationen an die Nutzer; d) einem oder mehreren Mobilnetzen und/oder WLAN-Netzen oder sonstigen Netzen und dass die Elemente der Anordnung nach dem Verfahren nach Anspruch 1-9 zusammenwirken, derart dass das oder die Netze (d) die Verbindung zwischen den Elementen der Anordnung ganz oder teilweise herstellen und die Kommunikation zwischen den Elementen (a) bis (c)

verfahrensgemäß unterstützt.

11. Verfahren zum Verhindern von unbefugtem Zugriff und unbefugter Übertragung von persönlichen und/oder sensiblen Daten durch Applikationen die auf einem mobilen Endgerät installiert sind, dadurch gekennzeichnet, dass alle Nutzerdaten jeweiligen Sensibilitätsklassen zugeordnet sind und je Sensibilitätsklasse eine Speichermarkierung besteht, die von einer StoreProtect klassengerecht verwaltet wird, derart dass eine Applikation all ihre beanspruchten Zugriffsrechte auf derart klassifizierte Daten zur Installationszeit der Applikation mit einem AccessProfil der StoreProtect bekannt macht, derart dass das AccessProfil von der StoreProtect sicher vor Manipulation durch Applikationen gespeichert wird, derart dass spätere Zugriffe der Applikation auf Daten mit Sensibilitätsklassifizierung, nur indirekt Uber die StoreProtect erfolgt, derart dass die StoreProtect die aktuelle Zugriffsanforderung der Applikation gegen die im AccessProfil abgelegten Zugriffsrechte prüft, und dann entweder ablehnt oder bei Berechtigung den Zugriff bestimmungsgemäß veranlasst, derart dass nur durch die StoreProtect kontrollierte Lesezugriffe und/oder Schreibzugriffe auf die Daten der jeweiligen Sensibilitätsklasse möglich sind.

12. Verfahren nach Anspruch 11 , dadurch gekennzeichnet, dass eine Sensibilitätsklasse auch

Geräten oder Teilgeräten eines mobilen Endgerätes zugewiesen ist, derart dass eine Applikation durch die StoreProtect kontrolliert auf folgende Geräte, aber nicht ausschließlich auf diese, zugreifen kann: eine Kamera und/oder ein Mikrofon und/oder ein Lautsprecher und/oder ein Thermometer und/oder ein Messgerät.

13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die StoreProtect nach der

Übermittlung des AccessProfil den Nutzer über die Zugriffmöglichkeiten der Applikation informiert und/oder von dem Nutzer generell oder in Teilen eine Bestätigung der Zugriffsrechte anfordert, derart dass die gegebenen und nicht gegebenen Bestätigungen in das AccessProfil einfließen und bei späteren Zugriffanforderungen durch die Applikation nach einer OR-Funktion oder nach vorgegebenen oder dynamisch erstellten Wahrheitstafeln berücksichtigt werden oder die

Deinstallation der Applikation veranlasst wird oder die noch bevorstehende Installation der Applikation nicht zugelassen wird.

14. Verfahren nach Anspruch 11-13, dadurch gekennzeichnet, dass die StoreProtect einzelne

Datenbanken oder Datenblöcke für die Verwendung in einer Sensibilitätsklasse durch

Applikationen, von dem Nutzer veranlasst oder bestätigt, zuweist oder den Zugriff für die entsprechende Sensibilitätsklasse freigibt, derart dass die StoreProtect den Zugriff durch einzelne Applikationen auf bestimmte Daten oder Daten von anderen Applikationen entsprechend der Auswahl durch den Nutzer kontrolliert.

15. Verfahren nach Anspruch 11-14, dadurch gekennzeichnet, dass die StoreProtect Teil des

Operating-Systems ist, derart dass die StoreProtect den gleichen Schutz vor Manipulation erhält wie das restliche Operating-System, derart dass die Überprüfung der Identität des Operating- Systems diejenige der StoreProtect mit impliziert.

16. Verfahren zur Eingabe von Nutzerdaten für Applikationen auf mobilen Endgeräten, dadurch

gekennzeichnet, dass die Applikation die Input vom Nutzer benötigt diesen nicht direkt anfordert sondern indirekt über eine InputProtect, die auf dem gleichen mobilen Endgerät installiert oder implementiert ist wie die Applikation, derart dass die InputProtect zum Zeitpunkt der Installation der Applikation ein InputProfil erhält mit Eingabedaten und deren Formate die die Applikation vom Nutzer anfordern kann, derart dass die Applikation per Index und/oder Namen die Inputdaten gegenüber der InputProtect benennt, derart dass die InputProtect diese Daten vom Nutzer anfordert und in einem von der Applikation nicht direkt zugänglichen aber nur für sie nutzbaren Bereich speichert, derart dass die Inputdaten nur per Index und/oder Namen von der Applikation via InputProtect weiterverwendet werden.

17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass das InputProfil auch Ressourcen bezeichnet, derart dass sie von der InputProtect als solche erkannt werden und für den Zugriff auf verschiedene Ressourcen von der InputProtect und/oder durch Zusammenwirken mit der StoreProtect verwendet werden, derart dass die Ressourcen-Bezeichnungen entsprechend dem Nutzer-Input, und durch die Applikation nicht verfälschbar, gezielt auf die vom Nutzer beabsichtigte Ressource zugegriffen wird.

18. Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass die Ressource ein Messaging System und/oder mobiles Banking-System ist und/oder eine Adresse oder eine Konto-Nummer innerhalb des jeweiligen Systems und/oder der Inhalt der Message, derart dass die Message durch die Applikation nicht verfälschbar ist und entsprechend des für den Nutzer sichtbaren Inputs übermittelt wird.

19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die InputProtect den entsprechend bezeichneten Input des Nutzers verschlüsselt, derart dass die InputProtect dies direkt durchführt und/oder durch Zusammenwirken mit anderen auf Vertrauenswürdigkeit geprüfte Entitäten entsprechend dem Zweck durchführt, derart dass die Anweisungen und Eingaben des Nutzers für diesen nachvollziehbar und unverfälscht erfolgt.

20. Verfahren nach Anspruch 1-19, dadurch gekennzeichnet, dass eine ConformCheck, die sich auf dem mobilen Endgerät befindet, die CheckApp und/oder die StoreProtect und/oder die

InputProtect und/oder das Operating-System prüft, derart dass eine Manipulation der originalen funktionalen Bestimmung der jeweiligen Entitäten festgestellt und/oder gespeichert wird und/oder für den Nutzer sichtbar angezeigt wird und/oder gegenüber Entitäten des Mobilnetzbetreibers und/oder des Herstellers des mobilen Endgerätes oder sonstigen Dritten übermittelt wird.

21. Verfahren nach Anspruch 20, dadurch gekennzeichnet, dass die ConformCheck und eine

ServConform, die sich auf einem Server befindet, miteinander Prüfdaten und/oder Prüfsummen und/oder Prüfalgorithmen verschlüsselt und/oder unverschlüsselt austauschen, derart dass die originale funktionale Bestimmung der Entitäten auf der Basis von verifizierten Daten geprüft wird.

Description:
Beschreibung

Verfahren zum Bewerten und Eindämmen von Risiken durch Smart-Phone-Applikationen.

Gegenwärtige Situation

Applikationen, auch Apps genannt, erfreuen sich großer Beliebtheit, da sie sich als nützlich für viele Bereiche des privaten und des geschäftlichen Lebens erweisen.

Obwohl die Mobilfunkkunden kaum auf diese Applikationen verzichten wollen, haben viele ein ungutes Gefühl mit Hinblick auf das Risiko, von der einen oder anderen Applikation ausspioniert zu werden oder dass dadurch auch Manipulationen an persönlichen Daten und oder Business-Daten

vorgenommen werden. Außer dem Auspionieren, droht von manchen Apps auch die Gefahr direkter monetärer Nachteile. Denn manche dieser bösartigen Apps senden SMS oder gar teure Premium

SMS. Bei hohem Daten-Volumen kann auch das Limit des Nutzers überschritten werden - soweit keine hinreichende Flatrate gebucht ist. Persönliche Daten können an dubiose Ziele (nicht autorisierte Server) versandt werden - unbemerkt vom Nutzer, auch bei Nacht, auch wenn das Handy vermeintlich unbenutzt ist.

Es sind Fälle bekannt, in denen auf ganz persönliche und sogar intime Bilder zugegriffen wurde und diese anschließend im Internet öffentlich gemacht wurden - mit erheblichem persönlichen Schaden der betroffenen Personen. Die Hintermänner befinden sich oft in Ländern in denen sie rechtlich nicht greifbar sind.

Applikationen können unbemerkt vom Nutzer das Mikrofon einschalten und/oder die Kamera und den Nutzer und seine Umgebung abhören oder fotografieren oder (video-)filmen. ;

„Schläfer" beginnen ihr böses Treiben erst einige Zeit (Wochen oder gar Monate) nach der Installation. Der Nutzer kann dann die oben genannten Phänomene oder auch Veränderungen an seiner

Telefonrechnung nicht mehr leicht zuordnen und keinen Zusammenhang mit dem Download der bösartigen Applikation erkennen.

Dem Nutzer werden im Rahmen von etablierten Abläufen von den gängigen Operating-Systemen der mobilen Endgeräte (Handys, Tabletts, etc.) Berechtigungen (Zugriffe auf Daten und/oder

Kommunikationskanäle wie Mobilnetz, WLAN, und/oder Geräte wie Kamera, Mikrofon, etc.) angezeigt. Diese Berechtigungen (Permissions) werden im Zusammenwirkten des Operating-Systems mit

Einrichtungen wie Market-Place oder AppStore, von denen die Applikationen typischerweise

runtergeladen werden, übergeben. Typischerweise sieht der Handy-Nutzer diese Berechtigungen nach dem Download und vor der Installation, meist im Zusammenhang mit der Abfrage einer Bestätigung ob die betreffende Applikation mit den aufgelisteten Berechtigungen installiert werden soll.

Diese Information über die Berechtigung ist häufig zu knapp gefasst, um vom Nutzer in ihrer ganzen Tragweite erfasst zu werden. Sie sagt auch kaum etwas darüber aus, welche persönlichen Daten wann und wofür verwendet werden. Auch sind einige Berechtigungen zu pauschal gefasst. Ein gutes Beispiel ist hier die„Interner -Berechtigung für ein kostenloses Spiel, bei dem der Entwickler über Anzeigen sein Geld verdient. Der Nutzer toleriert die Internet-Berechtigung, denn er versteht, dass die Anzeigen über das Internet von einem Ad-Server (Werbe-Server) geladen werden müssen. Was er nicht erkennen kann, mit welchen Servern das Spiel sonst noch kommuniziert.

Häufig werden viel zu umfangreiche Profile von den App-Designern angefordert. Dies bewirkt, dass der Nutzer den Eindruck gewinnt, die umfangreichen Berechtigungen seien ganz normal und werden von jeder Applikation benötigt. Die Akzeptanzschwelle wird durch diese Erfahrung gesenkt.

An der Stelle, wo der Reiz vorherrscht die Applikation jetzt zu installieren, stellen die meisten Nutzer die Bedenken hinten an. In der Tat gibt es vergleichbar wenig Missbrauch der Berechtigungen durch die Apps. Es werden zumindest nur wenige Fälle entdeckt. Das hängt auch daran, dass nur wenige Nutzer in der Lage sind, das Verhalten einer App mit Hinblick auf Missbrauch zu analysieren.

Es gibt zwar viele Foren in denen solche Fragen diskutiert werden, jedoch können diese nicht alle der vielen Hunderttausend Apps kennen und analysieren. Es fehlt auch eine vertrauensvolle Instanz, der man in dieser Frage Glauben schenken kann.

Verbesserung

Das hier beschriebene erfinderische Verfahren ist dem Bereichen mobile Applikationen, Apps, mobile Anwendungen, Schutz der Privatsphäre, und allgemein der Telekommunikation zuzuordnen.

Das Verfahren hilft einerseits, bösartige Applikationen unter den inzwischen auf viele

Hunderttausende gewachsene Zahl der Applikationen zu identifizieren und in einer anderen

Ausprägung (Anspruch 11-19) Transparenz der Aktionen einer jeden Applikation zu erzwingen und Manipulationen von Zugriffen und Zugriffsrechten wirksam zu unterbinden. Das Verfahren sorgt dafür dass die gutartigen Applikationen gezielt verwendet werden können und sogar noch reichlicher und vielfältiger - jetzt jedoch entspannter und ohne Bedenken.

Die Verfahren 11-19 ermöglichen eine formale Freischaltung des detaillierten Zugriffs- und

Kommunikationsverhaltens der Applikationen. Hierzu werden die Applikationen in Strukturen gefasst, die für die essentiellen Daten, die vor Manipulation zu bewahren sind, eine transparente Nutzung gewährleisten. Zu den Daten die zur Abwendung der oben genannten Gefahren kontrolliert werden müssen, gehören z.B.:

• Für die Kommunikation verwendete Zieladressen (Links, IP-Adressen, Telefonnummern, etc.);

• Für den Datenzugriff verwendete Sensibilitätsklassen (Persönliche Daten wie Bilder, Videos, Kalenderdaten, Telefon- und Adressbuch, Geschäfts-Dokumente, Pass-Wörter, etc.);

• Für den Ressourcen-Zugriff verwendete Identifier (Mikrofon, Kamera, GPS, Empfänger, etc.); Diese Daten werden von vertrauenswürdigen Entitäten, die sich auf dem jeweiligen Endgerät befinden und evtl. zum Operating-System gehören, separiert von den Applikationen, behandelt. Die

Applikationen haben nur indirekten Zugriff auf diese Daten, wie z.B. nur durch Indices und/oder Namen. Die jeweilige Applikation kann nicht direkt Operationen an den Größen ausführen. Sie kann nur im Rahmen der vorgegebenen begrenzten Funktionen, Anweisungen für die Verwendung der jeweils„ganzen" in sich unveränderten Größe geben (z.B.: verwende Adressel um eine Page im Internet zu öffnen; oder verwende Ressource-NamenX um das Mikrofon einzuschalten). Diese Adressen und Namen von Ressourcen sind gegenüber dem Nutzer zugänglich und jederzeit prüfbar und sind in manchen Fällen als Eingabe durch den Nutzer zustande gekommen - jedoch ohne „direkten" Kontakt mit der Applikation.

Mobile Endgeräten, die diese Verfahren (11-21) nicht verwenden, können die Verfahren 1-10 einsetzen. Letztere nutzen eine auf dem mobilen Endgerät installierte CheckApp, die die

Applikationen vor und/oder während und/oder nach der Installation prüft. Diese Prüfung kann rein lokal von der CheckApp auf dem mobilen Endgerät vorgenommen werden oder in Zusammenarbeit mit einer ServCheck, die sich auf einem verfahrensgemäßen Server befindet. ServCheck und CheckApp können jeweils ihre eigenen Knowledge-Datenbank aufbauen oder sie ganz oder teilweise auf den ServCheck hochladen, sodass die ServCheck auch andere mobile Endgeräte von der Erfahrung mit bereits bekannten Applikationen profitieren lassen kann.

Im Unterschied zu den Verfahren 11-19 können die Verfahren nach 1-10 Schaden für den Nutzer nicht gezielt verhindern, sie geben dem Nutzer jedoch die Information und Transparenz selbst zu entscheiden, ob er eine App installiert oder nicht.

In benutzerfreundlichen Ausprägungen der Verfahren unter 1-10 kann der Nutzer jederzeit das Profil und/oder die Aktivitäten und/oder die Zeiten der Aktivitäten und/oder ob die Aktivitäten der Applikation bei ausgeschaltetem Display stattgefunden haben, sehen. Eine leicht abrufbare Tabelle, listet z.B. die die Applikationen, die auf dem mobilen Endgerät des Nutzers installiert sind. Farbmarkierungen zu jeder Applikation geben ein Gesamtrating zum potentiellen und/oder eingetretenen Risiko. Durch Anklicken einer Applikation in der Liste erfährt der Nutzerweitere Details über potentielle und/oder bereits eingetretene Risiken, wie z.B.

• welches Volumen hat die Applikation in Aufwärts- und/oder Abwärtsrichtung übertragen; · auf weiche Daten (Bilder, Kontakte, Kalender, etc.) hat die App zugegriffen;

• welche sonstigen Ressourcen (Mikrofon, Kamera, etc.) hat die Applikation dabei einbezogen; • welche Kommunikationskanäle wurden dabei verwendet (WLAN, Mobilnetze, unter Roaming Bedingungen), und dergleichen.

Die CheckApp kann sowohl als Factory-Installation auf das mobile Endgerat gekommen sein oder sie wird vom Nutzer runtergeladen. In letzterem Fall sollte sichergestellt sein, dass der Download-Server von einer vertrauenswürdigen Entität kontrolliert und betrieben wird. Bei der Factory-Installation sollte die Bezugsquelle des mobilen Endgerätes ebenfalls als vertrauenswürdig geprüft sein - z.B. vom eigenen Mobilnetzbetreiber bezogen worden sein, der den diesbezüglichen Gesetzen des eigenen Landes unterliegt.