Apps stehlen Adressbuchdaten

[warlord]

Warum soll man, wenn der (Quell)code der Apss vorliegt, nicht nachprüfen können was die Apps treiben? Verstehe ich nicht.

Du möchtest aber nicht ernsthaft verlangen, dass Entwickler gegenüber Apple ihren Quellcode offenlegen müssen?

[radneuerfinder]

Ich will sagen, in einer kontrollierten Umgebung kann man systemimmanent - mit den entsprechenden Daumenschrauben - alles kontrollieren. Deswegen würde ich gerne diskutieren wie es geht. Und nicht ob.

Von Quellcodes habe i h keinen blassen Dunst. Das war von mir nur ein Buzzwort und Platzhalter für "nicht Unmöglichkeit".

[MacFlieger]

Warum soll man, wenn der (Quell)code der Apss vorliegt, nicht nachprüfen können was die Apps treiben? Verstehe ich nicht.

Apple hat den Quellcode nicht.
 

Warum soll nicht jede Adressbuchanfrage, die das iOS Gerät verlässt, zwingend über einen AppleServer (Server des  von mir beauftragten DatenschutzVereins) laufen, den der Nutzer individuell und Apple/DatenschutzStelle global auswerten und kontrollieren können?

Wie stellst Du sicher, dass eine App Adressbuchdaten überhaupt verschickt? Das ist prinzipiell gar nicht ermittelbar, außer eine App verschickt Daten offen.

Auch das von Dir verlinkte Programm zeigt nur Programme, die lokal auf das Adressbuch zugreifen. Aber es kann nicht(!) zeigen, wann unter welchen Umständen auf das Adressbuch zugegriffen wird, was mit den Daten geschieht, ob sie lokal verwendet (zu durchaus sinnvollen Sachen) werden, ob die Daten verschickt werden, ob nur Hashes oder nur notwendige Daten verschickt werden...

Nach meiner Überzeugung lässt sich in einer kontrollieren Zwangsumgebung - wie sie Apple für iOS Apps propagiert - auf jeden Fall was machen.

Wenn zwei Bedingungen zutreffen, dann ist immer und grundsätzlich der Missbrauch möglich und leicht so versteckbar, dass Apple ohne Quellcode nichts, aber auch gar nichts machen kann:
1. Die App darf auf das Adressbuch lokal zugreifen. Dafür gibt es viele sinnvolle Gründe und gerade in den betreffenden SM-Apps ist das sehr sinnig.
2. Die App darf Verbindungen ins Internet aufbauen. Auch dafür gibt es viele sinnvolle Gründe und die betreffenden SM-Apps benötigen das jeweils.
Ob die App nun die lokalen Daten nebenbei per Internetverbindung stiehlt, lässt sich ohne Quellcode nur in den simpelsten Fällen feststellen.

Daher sind die beiden Neuerungen (lokalen Zugriff aufs Adressbuch muss zugestimmt werden und der Benutzer soll eindeutig sein Einverständnis zum Hochladen erklären) gut, aber keine technische Sperre. Es ist nur so, dass diejenigen, die Daten stehlen wollen und das heimlich machen, sich später nicht mehr rausreden können, dass das aus Versehen passierte, so wie sie es jetzt tun. Allerdings kann das nur noch rauskommen, wenn in deren Firma jemand petzt.

Ich will sagen, in einer kontrollierten Umgebung kann man systemimmanent - mit den entsprechenden Daumenschrauben - alles kontrollieren. Deswegen würde ich gerne diskutieren wie es geht. Und nicht ob.

Gerne. Gerade das "Wie" würde mich sehr interessieren. Nach aktuellem Kenntnisstand ist das einzige "Wie", was tatsächlich funktioniert, das Disassemblieren der eingereichten App und Analyse dieses Paketes.
Die Umgebung ist allerdings weniger kontrolliert, als Du anscheinend vermutest.

[radneuerfinder]

Ja, ich hätte schon vermutet, daß wenn der Fachmann nur genau genug hinschaut, schon mitbekommt was Programme eigentlich treiben.

Der Treiber mit dem AutoUpdate (oder auch ohne) hat also meinen BenutzerOrdner schon vor 10 Jahren verschlüsselt und unbemerkt sonstwohin übergertragen?? Teufelswerk! Da vergeht mir ja gleich die Lust überhaupt noch irgendwas elektronisch zu speichern.

[Florian]

Wir stoßen hier natürlich wieder mal auf die Ursprungsfrage von einst: Was soll dieser Appstore eigentlich, ausser bestimmte Funktionen Apple selbst vorzubehalten? (Vertriebsrecht, 30%, usw. mal beiseite.)

Mir ist klar, dass Disassembling extrem aufwendig ist. Zudem in den USA wohl auch rechtlich problematisch (hier könnte Apple wohl vertraglich nachjustieren).
Tut Apple irgendwas dergleichen? Sieht nicht so aus. Hier läge ein Teil der Lösung. Und warum sollen die begabtesten Tüftler nicht auch Algorithmen entwickeln können, wie man Verhalten von Apps einordnet? Warum funkt es jetzt heim, wie groß ist die Datenmenge, fand zuvor ein Zugriff auf private Daten statt, etc. pp.
So total wehrlos wie hier argumentiert ist ein Multimilliardendollarkonzern wohl kaum. Und die Apple-Anwälte klagen auch gerne jeden bösen App-Entwickler in die Pleite, wenn sie den Auftrag dafür bekommen.

Das ich null Zutrauen in Apples Sicherheitsbemühungen habe, liegt auch an anderen Fällen. Wer auf der Welt weiß nicht, das Pokémon eine geschützte Marke ist? Warum sind so viele Scam-Apps immer wieder in den Charts? Warum werden festgestellte Sünder nicht publikumswirksam an den Pranger gestellt?

Man will uns den sicheren Appstore vorgaukeln, der nie existierte. Das dann die Wünsche an Apple groß sind, ist nur logisch. Das Apple dann sagt: Geht nicht anders! (bzw. gar nix), und nur Scheinlösungen umsetzt, finde ich schon bedenklich.

Es gäbe im Store auch sonst viel zu tun, von den Reviews bis zu Demos und Videos. Das man die Katze im Sack kaufen muss, ist auch ein Teil des Problems.

[mbs]

Mir ist klar, dass Disassembling extrem aufwendig ist.

Ist das Dein Ernst? Du weißt, dass ein Disassemblieren einer 4$-App mit dem Versuch, das Ergebnis zu verstehen, locker 40.000$ kosten würde?

Und warum sollen die begabtesten Tüftler nicht auch Algorithmen entwickeln können, wie man Verhalten von Apps einordnet?

Das versuchen Abertausende von Informatikern seit 60 Jahren. Es ist in der Praxis bis heute nicht machbar. Und für den allgemeinsten Fall (wenn man die theoretische Menge aller "programmierbaren Programme" betrachtet) kann man sogar mathematisch beweisen, dass dieses Problem für immer und ewig unlösbar bleiben wird. Wie gesagt, nicht nach dem derzeitigen Stand von Technik und Forschung unlösbar, sondern - weil rein mit Logik herleitbar - für immer ausgeschlossen.

Ich stimme Deiner Kritik am AppStore grundsätzlich zu. Man muss allerdings gleichzeitig sagen, dass Apple meines Wissens nie behauptet hat, der App Store wäre in irgendeiner Weise "sicher" oder die Apps hätten irgendwelche zugesicherten Sicherheitseigenschaften. Das ist provokativ gesagt eine reine Erfindung von Apple-Fans, mit der zu Anfang die Einführung des "App-Review"-Prozesses schöngeredet wurde.

[Florian]

Ist das Dein Ernst? Du weißt, dass ein Disassemblieren einer 4$-App mit dem Versuch, das Ergebnis zu verstehen, locker 40.000$ kosten würde?

Ja, so ungefähr hätte ich schon geschätzt.
Auch das Durchleuchten eines offenen Quellcodes ist ja schon ganz schön aufwendig und teuer.

Aber gehen wir doch mal von der anderen Seite heran: Was ist Apple der Appstore und sein Funktionieren wohl wert?
Jetzt wird wieder diskutiert, auch weil Cook fröhlich Andeutungen macht, der Geldberg würde über Dividenden abgeschmolzen, also zugunsten der Shareholder. Apple könnte damit aber auch andere Sachen finanzieren, zum Wohle anderer Stakeholder.

Wie gesagt: Natürlich müsste es bei Stichproben bleiben, verbunden mit „kriminalistischem Gespür“.

Wie gesagt, nicht nach dem derzeitigen Stand von Technik und Forschung unlösbar, sondern - weil rein mit Logik herleitbar - für immer ausgeschlossen.

Das sehe ich schon ein. 
Apple setzt aber doch enge Grenzen, was man so programmieren darf und es geht v.a. um den Datenverkehr. Ist es da wirklich nicht möglich, gewisses Verhalten zumindest verdachtsmäßig einzuordnen, um die Stichprobenkandidaten einzuengen?

Ich stimme Deiner Kritik am AppStore grundsätzlich zu. Man muss allerdings gleichzeitig sagen, dass Apple meines Wissens nie behauptet hat, der App Store wäre in irgendeiner Weise "sicher" oder die Apps hätten irgendwelche zugesicherten Sicherheitseigenschaften. Das ist provokativ gesagt eine reine Erfindung von Apple-Fans, mit der zu Anfang die Einführung des "App-Review"-Prozesses schöngeredet wurde.

Naja! Aus der iPhone-SDK-Vorstellung:

[warlord]

Ich muss da Florian doch etwas unterstützen. Ich denke auch, dass mehr möglich wäre. Dazu ist IMO kein aufwendiges Reverse-Engineering aller Apps notwendig. Ein Programm läuft ja nicht im luftleeren Raum, sondern in einem Betriebssystem, dessen APIs es nutzt; für viele Dinge nutzen muss, gerade auf hardwaremässig geschlossenen Systemen wie es Mac und erst recht iOS-Geräte sind. Da ist es IMO durchaus möglich, Testumgebungen zu bauen, die anhand der zeitlichen Abfolge der aufgerufenen APIs einen Eindruck vermitteln können, was eine App so treibt. Und so mindestens eine Risikobeurteilung erlauben, mit der sich verdächtige Apps aussortieren und einer genaueren Untersuchung unterziehen lassen.

Sicher, wer es wirklich darauf anlegt, wird auch unter einem solchen Radar durchfliegen können. Aber ob es noch mit einem vertretbaren Aufwand möglich ist, wenn man für sinistre Funktionen APIs meiden und das Rad komplett selbst neu erfinden muss, ist halt die Frage. Gelegenheits-Sünder dürften sich so jedenfalls erwischen lassen. Und für die Profi-Sünder wird es aufwendiger und teurer.

[MacFlieger]

Der Treiber mit dem AutoUpdate (oder auch ohne) hat also meinen BenutzerOrdner schon vor 10 Jahren verschlüsselt und unbemerkt sonstwohin übergertragen?? Teufelswerk! Da vergeht mir ja gleich die Lust überhaupt noch irgendwas elektronisch zu speichern.

Ich bin mir nicht sicher, ob Du das ironisch meinst oder nicht.
Ja, auf dem Rechner kann jedes Programm ein trojanisches Pferd sein. Da gibt es aktuell gar keine Sicherungen außer, dass Programme, die systemweit arbeiten wollen, bei der Installation ein Admin-Kennwort brauchen.
Zu dem Beispiel:
Auto-Updates lassen sich recht gut testen, da dessen Anfragen üblicherweise nicht verschlüsselt sind. Ist in dem Fall auch nicht notwendig.
Bei allen Programmen, die verschlüsselt kommunizieren sollten und es auch tun, kann man nicht wissen, was sie machen. Wenn man es durch einfaches Belauschen der Kommunikation oder Man-in-the-middle herauskriegen könnte, dann wäre die Verschlüsselung nichts wert und man könnte gleich drauf verzichten. Gerade aber bei Kommunikation in fremden Netzen (bei mobilen Geräten üblich) ist Verschlüsselung eigentlich Pflicht. AFAIR ist z.B. bis heute nicht geklärt, was  die Windows-Aktivierung für Daten genau verschickt. Da gibt es nur Hinweise, welche Daten alles mindestens mit eingehen. Und da haben sicher einige Leute an Hirnschmalz und Zeit investiert, um das ergründen.

Zum "durch Apple kontrollierten System":
Was ist da wirklich kontrolliert/eingeschränkt?
AFAIK:
- die Apps laufen in einer Sandbox und können nur über ihre eigenen Daten völlig verfügen. Zu fremden Daten (z.B. Adressbuch) und Schnittstellen (z.B. Netzwerk) muss über vorgegeben APIs zugegriffen werden.
- beim Review wird geschaut, ob die App inhaltlich verbotenes offensichtlich macht (Nacktheit, Tethering...)
- beim Review wird geschaut, ob die App nicht offensichtlich sofort abstürzt.
- beim Review wird geschaut, ob nur offizielle APIs benutzt werden.
- was die App in sich selber drin macht wird nicht überprüft und kann aus dargelegten Gründen auch nicht in vertretbarem Rahmen.

@mbs:
Danke, ich dachte schon langsam, ich würde da völlig falsch liegen.

Apple setzt aber doch enge Grenzen, was man so programmieren darf und es geht v.a. um den Datenverkehr. Ist es da wirklich nicht möglich, gewisses Verhalten zumindest verdachtsmäßig einzuordnen, um die Stichprobenkandidaten einzuengen?

und

Da ist es IMO durchaus möglich, Testumgebungen zu bauen, die anhand der zeitlichen Abfolge der aufgerufenen APIs einen Eindruck vermitteln können, was eine App so treibt. Und so mindestens eine Risikobeurteilung erlauben, mit der sich verdächtige Apps aussortieren und einer genaueren Untersuchung unterziehen lassen.

Das ist sicher möglich. In dem vorliegenden Fall sucht man alle Apps heraus, die über die offiziellen APIs auf das Adressbuch zugreifen (so eine Software hat radneuerfinder ja verlinkt) und Datenverbindungen benutzen. Damit hast Du die "verdächtigen Apps". Da derartiges für sehr viele Apps und bei den betreffenden SM-Apps grundsätzlich der Fall ist, kann man dann loslegen und diese "durchleuchten". Das wird dann viele Wochen/Monate, zusätzliche Spezialisten in der Analyse von disassembliertem Code (wird es nicht viele geben und garantiert nicht billige) und Geld kosten. Das ganze dann bei jedem Update. Völlig unrealistisch.

[warlord]

Das ist sicher möglich. In dem vorliegenden Fall sucht man alle Apps heraus, die über die offiziellen APIs auf das Adressbuch zugreifen (so eine Software hat radneuerfinder ja verlinkt) und Datenverbindungen benutzen. Damit hast Du die "verdächtigen Apps". Da derartiges für sehr viele Apps und bei den betreffenden SM-Apps grundsätzlich der Fall ist, kann man dann loslegen und diese "durchleuchten". Das wird dann viele Wochen/Monate, zusätzliche Spezialisten in der Analyse von disassembliertem Code (wird es nicht viele geben und garantiert nicht billige) und Geld kosten. Das ganze dann bei jedem Update. Völlig unrealistisch.

Ne, ne, da hast Du mich falsch verstanden. Ganz so einfach sollte dieses Testsystem schon nicht sein, dass nur statisch angeschaut wird, greift die App auf das Adressbuch zu. Genau diesen relativ simplen Punkt dürfte ja wohl die von radneuerfinder verlinkte App anschauen. Und der bringt natürlich wenig.
Aber eine App ruft ja nicht nur die Adressbuch-APIs auf, sondern in ständiger Folge die unterschiedlichsten APIs. Analysiert die Testumgebung, in der die App läuft, in welcher zeitlicher Folge all diese APIs aufgerufen werden, ergibt das durchaus ein Bild von dem, was die App so treibt.

Und weil Apps ja eben für vieles APIs heranziehen (müssen), ist Apple auch der Verschlüsselung nicht so hilflos ausgeliefert, wie Du es darstellst. Welche App implementiert die Verschlüsselung schon selbst? Die nutzen dazu APIs. Nicht die App, sondern Apple, bzw. das von ihnen gebaute System, verschlüsselt diese Daten und kriegt diese also durchaus im Klartext in die Finger.

[MacFlieger]

Und weil Apps ja eben für vieles APIs heranziehen (müssen), ist Apple auch der Verschlüsselung nicht so hilflos ausgeliefert, wie Du es darstellst. Welche App implementiert die Verschlüsselung schon selbst? Die nutzen dazu APIs. Nicht die App, sondern Apple, bzw. das von ihnen gebaute System, verschlüsselt diese Daten und kriegt diese also durchaus im Klartext in die Finger.

OK, stimmt. Da könnte man eine weitere Hürde für Böse einbauen.
Wobei die dann auch dazu übergehen könnten, selber zu verschlüsseln (ist nicht schwer) und/oder das Böse erst zu starten, wenn die App nicht im Review läuft.
Es geht ja hier um "böse" Apps. Man sollte auch im Hinterkopf behalten, dass die sich echt anstrengen, um Sicherheitssperren zu umgehen, siehe Google umgeht Sicherheitssperren in Safari und IE. Das war ziemlich kompliziert und aufwändig. Und was passierte als sie erwischt wurden? Ein kleines "Dududu, du böses Google" und das Unterlassen dieser Methode. Die suchen garantiert schon nach einer Neuen.

Für mich ist echt die wichtigste Methode: Harte Strafen androhen und(!) umsetzen. Das hilft zwar technisch  absolut nichts, aber schreckt ab. Vor allem wenn erst einmal ein paar erwischt und abgestraft wurden. Und nicht so läppische Strafen wie "Ausschluss aus dem AppStore", bei denen die Schwergewichte wie Facebook und Google sich sicher sein können, dass das nicht stattfinden wird...

[warlord]

Wenn man einen kontrollierten(*) Store anbietet, dann gehört da für mich beides dazu, Kontrolle und Konsequenzen. Aber angemessene Konsequenzen. Nur harte Strafen können es nicht sein. Es kann nicht sein, dass ein kleiner Entwickler seine Existenzgrundlage verliert, weil er Zeile 14235 der 56376 zeiligen Nutzungsbedingungen überlesen oder nicht richtig verstanden hat.

Und ich schrieb ja schon:

Sicher, wer es wirklich darauf anlegt, wird auch unter einem solchen Radar durchfliegen können.

Wer das dann aber eben tut, der hat nicht nur Zeile 14235 überlesen. Der weiss dann sehr genau, was er tut, und tut es mit Vorsatz. Entsprechend können die Konsequenzen anders ausfallen. Und ja, da sollte dann auch "Unternehmensräson" keinen Einfluss mehr haben. Und die Konsequenzen für alle (dann eben eindeutigen) Sünder vergleichbar sein. (Aber gut, dass Apple diesen Mut bei Google nicht aufbringt, kann ich verstehen. Bei Twitter allerdings weniger. Eine Plattform ohne Twitter ist sicher nicht unattraktiver, als eine Plattform ohne Flash...)

(*) Und Apple kontrolliert ja unbestrittenermassen. Publik wurden bis jetzt ja primär Fälle inhaltlicher Kontrolle. Kontrollen also, auf die das Publikum nicht wirklich angewiesen wäre, weil es diese Beurteilung durchaus selbst vornehmen kann. Zumindest erwachsene Individuen. Die Kontrollen, die für das Publikum hilfreicher wären, sind die technischer Art, zu der das Publikum eben nicht selbst in der Lage ist. Von solchen ist bis jetzt wenig publik geworden. (Was nicht heissen muss, dass nicht auch Apps daran gescheitert sind. Aber die Anzahl publik gewordener Fälle ist immerhin ein Indiz.) Da gehe ich mit Florian jedenfalls durchaus einig, dass da eine Verlagerung der Kontrolltätigkeit durchaus sinnvoll (und machbar) wäre. Weg von Kindergarten-Kontrollen hin zu Profi-Kontrollen.

[mbs]

Welche App implementiert die Verschlüsselung schon selbst? Die nutzen dazu APIs.

Jein. Leider ist die Sachlage in der Regel etwas komplexer und wie MacFlieger schon gesagt hat, wäre es nicht schwer, die APIs zu umgehen.

Es gibt mögliche Angriffsszenarien gegen das DRM-Verfahren des App Store, bei dem die Verschlüsselungsbibliothek des Systems (libcrypto) gegen eine manipulierte Version ausgetauscht wird, so dass das System beliebige Apps ohne Kontrolle von Rechner und Apple-ID freischaltet.

Um diese Lücke zu schließen, ist es Apples offizieller Ratschlag für Apps, nicht gegen die Systembibliotheken zur Verschlüsselung zu linken, sondern die üblichen Crypto- und SSL-Verfahren statisch zur Compile-Zeit gegen eigene Bibliotheken zu binden. Da OpenSSL mit allen üblichen Verfahren kostenlos genutzt werden darf, ist das nicht schwer. Die Verschlüsselungsverfahren werden dadurch zu internen Funktionen der App und laufen nicht mehr übers Betriebssystem.

Da hast aber insofern recht, dass die entsprechenden Funktionsaufrufe trotzdem von außen erkennbar wären. Die Entwickler müssen zwar nicht den Quellcode, wohl aber die komplette Symboltabelle des Codes beim Review einreichen. Aufrufe zur Verschlüsselung wären also immer noch an ihren Namen sichtbar. Wenn man aber nun tatsächlich genug kriminelle Energie hineinsteckt, ließe sich das natürlich durch einfache Umbenennung der APIs leicht verschleiern.

Es ist aber durchaus so, dass Apple bereits seit langem jede App und jedes Update mithilfe einer Spezial-Sandbox durchleuchtet und jeden API-Aufruf prüft. Eine App, die ohne Verwendung der offiziellen Preferences-APIs Dateien im Ordner Library/Preferences schreibt, wird zum Beispiel sofort abgelehnt. Die beiden Vorgänge "Lesen des Adressbuchs" und "späteren Senden irgendwelcher HTTP-Daten" finden aber auf einer so hohen Abstraktionsebene statt, dass sie mit solchen Maßnahmen nicht mehr in einen direkten Zusammenhang gebracht werden können. Bei der in den USA ganz anderen Mentalität, bei der das Zeigen nackter Haut stark sanktioniert ist, das Abgreifen persönlicher Daten jedoch kaum, ist es dann kein Wunder, dass Apps durch das Review-System schlüpfen, die wir als Malware einstufen würden.

Im Grunde sind wir uns aber wohl alle einig, dass der App Store Sicherheit suggeriert, die er nicht bietet, und dass Apple aus unserer europäischen Sicht oft völlig falsche Prioritäten bei der Prüfung von Apps setzt. Unsere abweichenden Meinungen sind eher technischer Natur, dass nämlich die Leute, die selbst programmieren, wissen, dass das Garantieren bestimmter Sicherheitseigenschaften sehr, sehr viel schwieriger und teurer ist, als man sich das gemeinhin vorstellt.

[MacFlieger]

Wer das dann aber eben tut, der hat nicht nur Zeile 14235 überlesen. Der weiss dann sehr genau, was er tut, und tut es mit Vorsatz. Entsprechend können die Konsequenzen anders ausfallen.

Das meinte ich.
Nicht eine harte Strafe für alle "Vergehen" sondern eben für solche absichtlichen Verstösse richtig hartes Kaliber, aber nicht von Apple, weil die gar nicht hart genug bestrafen können.
Es sollten staatliche Strafen mit empfindlichen Geldbußen sein bei absichtlichen Verstößen gegen Datenschutz und Stehlen von Daten. Meinetwegen prozentual vom Umsatz um die großen härter zu treffen.
Über Ausschluss aus dem AppStore können doch die Großen nur lachen. Das kann sich Apple gar nicht erlauben.

Eine Plattform ohne Twitter ist sicher nicht unattraktiver, als eine Plattform ohne Flash...)

Das ist für mich und Dich sicher richtig, aber Du kannst Dir sicher vorstellen, was durch die Presse und Öffentlichkeit geht, wenn man plötzlich nicht mehr twittern kann...
Außerdem ist Flash eine andere Geschichte. AFAIR hat Adobe nie eine vernünftig laufende Flashversion vorgeführt.

[warlord]

Um diese Lücke zu schließen, ist es Apples offizieller Ratschlag für Apps, nicht gegen die Systembibliotheken zur Verschlüsselung zu linken, sondern die üblichen Crypto- und SSL-Verfahren statisch zur Compile-Zeit gegen eigene Bibliotheken zu binden. Da OpenSSL mit allen üblichen Verfahren kostenlos genutzt werden darf, ist das nicht schwer. Die Verschlüsselungsverfahren werden dadurch zu internen Funktionen der App und laufen nicht mehr übers Betriebssystem.

Tja, das kommt wohl darauf an, wo man in Apples furchtbar lückenhafter, widersprüchlicher und oft schlicht falscher Dokumentation zum Thema Sicherheit und Verschlüsselung gerade nachliest.    Zum Thema OpenSSL schreibt Apple zum Beispiel auch (im Cryptographic Services Guide):

Although OpenSSL is commonly used in the open source community, OpenSSL does not provide a stable API from version to version. For this reason, although Mac OS X provides OpenSSL libraries, the OpenSSL libraries in Mac OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the Mac OS X OpenSSL libraries by applications is strongly discouraged.

Aber ja. Es geht dann noch weiter. 

If your application depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your application. This use of OpenSSL is possible on both Mac OS X and iOS. However, unless you are trying to maintain source compatibility with an existing open source project, you should generally use a different API.

Common Crypto and Security Transforms are the recommended alternatives for general encryption. CFNetwork and Secure Transport are the recommended alternatives for secure communications.