Ist dieser Plan, um zu verhindern, dass der iPhone App-Client den Sound verfälscht?

Question

Ich entwerfe eine iPhone App, die über HTTP mit einem Server kommuniziert.

Ich möchte nur die App, nicht beliebige HTTP-Clients, um bestimmte URLs auf dem Server POST zu können. Daher richte ich den Server so ein, dass nur POSTs mit einem geheimen Token validiert werden, und richte die App so ein, dass sie dieses geheime Token enthält. Alle Anfragen, die dieses Token enthalten, werden nur über eine HTTPS-Verbindung gesendet, so dass sie nicht beschnüffelt werden können.

Sehen Sie irgendwelche Fehler mit dieser Argumentation? Wäre es beispielsweise möglich, das Token mit "Strings", einem Hex-Editor usw. aus der kompilierten App auszulesen? Ich würde dieses Token natürlich nicht in einem .plist- oder anderen Klartext-Format speichern.

Vorschläge für ein alternatives Design sind willkommen.

Answer 1

Im Allgemeinen wird angenommen, dass ein entschlossener Angreifer keinen Schlüssel entdecken kann, der in die Anwendung auf einem Gerät unter seiner physischen Kontrolle eingebettet ist (und wahrscheinlich, dass er sowieso besitzt). Sehen Sie sich alle gebrochenen DRM-Schemata an, die auf dieser Annahme beruhen.

Was wirklich wichtig ist, ist wer versucht, den Schlüssel zu bekommen, und was ihr Anreiz ist. Verkaufe ein Produkt, das auf eine Zielgruppe abzielt, die nicht stehlen möchte. Bewerten Sie Ihr Produkt so, dass es billiger ist, es zu kaufen, als den Schlüssel zu entdecken. Bieten Sie Ihren Kunden einen guten Service. Dies sind alles Marketing- und Rechtsfragen, nicht technologische.

Wenn Sie einen Schlüssel einbetten, verwenden Sie eine Methode, bei der jeder Client den Schlüssel selbst ermitteln muss, z. B. dass für jeden Client ein anderer Schlüssel erforderlich ist. Sie möchten keine Situation, in der ein Angreifer den Schlüssel erkennen und veröffentlichen kann und allen Benutzern Zugriff gewährt.

Die iPhone does provide the "KeyChain" API,, die der Anwendung helfen kann, Geheimnisse vor dem Besitzer des Geräts zu verstecken, für besser oder schlechter. Aber alles ist zerbrechlich.

Answer 2

Ich schlage vor, basierend auf den gesendeten Daten und einem geheimen Schlüssel, den Ihre App und der Server kennen, eine Prüfsumme (md5/sha1) hinzuzufügen.

Answer 3

So wie ich es verstehe, ja, könnte der Schlüssel aus der App auf die eine oder andere Weise abgerufen werden. Es ist fast unmöglich, etwas in der Objective-C-Laufzeit aufgrund seiner Natur zu verstecken. Nach meinem besten Wissen haben nur Omni es mit ihren Seriennummern geschafft, anscheinend indem sie den kritischen Code in C behalten (Cocoa Insecurity).

Es könnte eine Menge Arbeit sein (ich habe keine Ahnung, wie komplex es zu implementieren ist), aber Sie könnten die Push-Benachrichtigungen in Betracht ziehen, um einen Authentifizierungsschlüssel mit einer Gültigkeit von einer Stunde an das Programm zu senden Stunde. Dies würde das Problem der Überprüfung, dass es sich bei Ihrer App um Apple handelt, weitgehend beseitigen.

Answer 4

Anwendungen können zerlegt werden, damit sie Ihren Schlüssel finden können.

Answer 5

Weitere Informationen werden benötigt, um zu bestimmen, ob der Ansatz vernünftig ist. Es kann sinnvoll sein, dass ein Vermögenswert geschützt und für einen anderen ungesund ist, und zwar basierend auf dem Wert des Vermögenswertes und den Kosten, wenn der Vermögenswert aufgedeckt wird.

Mehrere frühere Poster haben darauf hingewiesen, dass alles auf dem Gerät von einem entschlossenen Angreifer enthüllt werden kann. Das beste, was Sie tun können, ist, den Wert des Assets zu bestimmen und dem Angreifer genug Hürden zu setzen, dass die Kosten des Angriffs den Wert des Assets übersteigen.

Man könnte zu Ihrem Schema clientseitige Zertifikate für das SSL hinzufügen.Man könnte dieses Zertifikat und den Schlüssel für das Token tief in irgendeinem verschleierten Code vergraben. Man könnte wahrscheinlich ein Schema erstellen, das eine Kryptographie mit öffentlichem/privatem Schlüssel verwendet, um das Token weiter zu verdecken. Man könnte ein Challenge/Response-Protokoll implementieren, das eine Zeitfenster-Reaktionszeit aufweist, in der der Server die App herausfordert und die App X Millisekunden lang reagiert, bevor sie getrennt wird.

Die Anzahl und Komplexität der Hürden hängt vom Wert des Assets ab.

Jack

Answer 6

Sie in die Entrust Technologies (www.entrust.com) Produktlinie für die Zwei-Faktor-Authentifizierung für alle Arten von Besonderheiten (zB Gerät, IMEI, Anwendung Seriennummer, Benutzer-ID gebunden aussehen sollte, etc.)