Apps und Verschlüsselung - Erfahrungen mit der US Export Registrierung (ERN)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Apps und Verschlüsselung - Erfahrungen mit der US Export Registrierung (ERN)

    Hallo,

    lädt meine eine neue App oder ein Update in ITC hoch, wird ja die Frage gestellt, ob die App Verschlüsselungstechniken enthält. Wenn dem so ist und die Verschlüssung nicht unter bestimmte Ausnahmen fällt muss man eine Exportgenehmigung - Encryption Registration Number (ERN) - vom "Bureau of industry and security" des US Department of Comerce beantragen.

    Bislang war das für meine Apps nicht notwendig. Ich will nun aber eine Exportfunktion integrieren die verschlüsselte Dateien erzeugen kann. Laut Checkliste ist das ein Fall für eine ERN. Hat jemand hier Erfahrung mit diesem Procedere? Wie aufwändig ist das Ganze und vor allem wie lange dauert der Ganze Prozess? Muss ich also jetzt anfangen wenn ich die App im Sommer veröffentlichen will oder bekommt man die ERN quasi umgehend?

    Für Tipps und Erfahrungswerte wäre ich wirklich dankbar!
  • Tja, genau so einen Fall würde ich gerne vermeiden. Ich finde es zwar nicht besonders einleuchtend warum Erstellung und Versand einer Verschlüsselten ZIP-Datei genehmigungspflichtig ist, aber das ist ja nicht der Maßstab. Wenn also jemand Erfahrung mit dem Verfahren hat wäre ich sehr dankbar!

    Ich kann mir kaum vorstellen, dass hier noch nie jemand mit diesem Thema konfrontiert wurde. Man benötigt die Registrierung ja quasi schon, wenn man eine SSL bzw. HTTPS Verbindung verwendet. Auch wenn noch niemand das Verfahren durchgemacht hat, wäre die Information "ich habe darauf verzeichtet weil..." hilfreich. Ich sags auch keinem weiter :)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Agenor ()

  • Wenn ich Damen und Herren aus den Schurkenstaaten Technik für die Verschlüsselung von Kommunikation, etc. liefere kann ich das Procedere ja noch verstehen. Wenn ich aber eine App für 89 Cent anbiete die eine verschlüsselte ZIP-Datei erstellt oder mit einem HTTPS Server redet, ist das totaler bürokratischer Unsinn. Das ist Technik die bereits dem gesamten Planeten zur Verfügung steht.
  • Ich habe das so verstanden, dass der Export von Verschlüsselungstechnologien genehmigt werden muss.
    Solltest Du also mit Bordmitteln einen Private Key erstellen und damit Daten verschlüsseln ist das kein Export von Technologien.

    Wenn Dir das alles zu kompliziert ist, kannst Du die Daten an einen Server schicken (meinetwegen HTTPS), dort verschlüsseln und mit der App wieder herunterladen.

    Es geht dabei meines Wissens nach nur um den Akt der Verschlüsselung auf dem Gerät durch Algorithmen die von Dir implementiert wurden.
    Sonst hätte jede App die zum Beispiel SSH emuliert oder jede Chat App die ihre Daten selber verschlüsselt viel zu viele Hürden zu überwinden.
  • @pmau

    Du hast absolut recht, dass jede App die irgendeine Verschlüsselung verwendet viel zu viele Hürden zu überwinden hätte. Allerdings muss man das "hätte" hier durch ein "hat" übersetzten, denn es ist wirklich so.
    - Es spielt keine Rolle ob die Verschlüsselung selbst implementiert ist oder nicht
    - Es spielt keine Rolle ob die Verschlüsselung mit Funktionen des Systems ausgeführt wird oder z.B. irgendeine Lib von Dritten verwendet wird
    - Es spielt keine Rolle ob die App was kostet oder nicht
    - Es spielt keine Rolle wo der Entwickler sitzt, denn Apple sitzt in den USA

    Auf der Webseite des US BIS ist ziemlich genau erklärt was alles eine Genehmigung braucht und das ist quasi alles. Es gibt nur einige wenige Aussnahmen (z.B. für Verschlüsselung von Gesundheitsdaten, Verschlüsselung für Lizenzcontrolle, etc.) Aber auch diese Fälle sind genehmigungspflichtig, man darf sich die Genehmigung aber selbst erteilen. Einzige echte Ausnahme ist Verschlüsselung die quasi veraltet ist (sehr kurze Schlüssellängen, etc.) und damit eigentlich keine Verschlüsselung mehr ist.

    Beim Absenden einer neuen App Version im Store fragt Apple explizit ob Verschlüsselung verwendet wird und weißt dabei darauf hin, dass es egal ist ob diese mit Bordmitteln erstellt wurde oder nicht.

    Das ist ja gerade der komplette Unsinn. Jedes kleine Fitzelchen ist Genehmigungspflichtig. Der bürokratische Aufwand ist riesig und der Nutzen (zumindest im Fall von Apps) marginal wenn nicht gleich Null. Aber so ist es eben. Man hat also nur drei Möglichkeiten:

    1. Den ganzen Prozess mitmachen und sich um eine Genehmigung kümmern.
    2. Mit den US Behörden über Sinn und Unsinn des Ganzen diskutieren
    3. In die Luft gucken, ein Liedchen pfeifen und hoffen, dass keiner was sieht.

    Ich persönlich finde die Lösungen 2 und 3 nicht so optimal. Ob Lösung 1 für ein kleines Hobbyprogrämmchen die richtige Wahl ist muss man aber auch erst einmal für sich entscheiden. Vielleicht bleibt ja noch weg 4: Falls in der App die Verschlüsselung nicht unbedingt notwendig ist einfach darauf verzichten.
  • Agenor schrieb:

    muss man aber auch erst einmal für sich entscheiden. Vielleicht bleibt ja noch weg 4: Falls in der App die Verschlüsselung nicht unbedingt notwendig ist einfach darauf verzichten.


    Das ist natürlich Unsinn. Selbst wenn man so wenig Verantwortung für die Daten seiner User übernehmen will, verweise ich noch auf den Vortrag von Thomas auf der Macoun ("Datenschutz"). Da schlage klicke ich mich lieber durch ein Formular für eine Kryptogenehmigung als mich mit einem deutschen Landesdatenschutzamt anzulegen. ;)
  • Da schlage klicke ich mich lieber durch ein Formular für eine
    Kryptogenehmigung als mich mit einem deutschen Landesdatenschutzamt
    anzulegen.


    Da gebe ich dir natürlich absolut recht. Aber wird bestimmt einige Fälle geben wo man (ausnahmsweise) mit keiner Behörde kollidiert, wenn die Daten nicht verschlüsselt. Ich kenne z.B. eine kleine Notizapp bei der man seine Daten gezipped per Mail verschicken kann. Dass man die Zip-Datei dabei verschlüsseln kann ist natürlich ein netter und sinnvoller Zusatznutzen aber absolut notwendig ist das wohl nicht. In solchen Fällen würde ich mich dann fragen, welcher Aufwand im gesunden Verhältnis zum Nutzen steht.

    Allgemein denke ich aber, dass Lösung 1, also der Gang durch die Behörden, in jedem Fall die beste Lösung ist. Natürlich kann man sich dabei über den bürokratischen Unsinn ärgern, mit dem man gerade seine Zeit verplempert, aber das gehört einfach dazu.
  • Agenor schrieb:

    Auf der Webseite des US BIS ist ziemlich genau erklärt was alles eine Genehmigung braucht und das ist quasi alles.

    Kennt eine(r) von Euch eigentlich eine Quelle, in der sich Apple einmal zu diesem Thema verbindlich äußert? Streng genommen müsste ja eigentlich jeder Entwickler das "Krypto-Häkchen" bei Einreichen eines Updates setzen: Schliesslich ist der Code mittels kryptographischer Methoden signiert worden. Oder wie sieht es bei Verwendung von NSURLConnection, um eine HTTPS-Verbindung aufzubauen ... Top oder Flop? Oder ... oder ... oder ...

    Ich finde, hier wird man ganz schön im Regen stehen gelassen.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MyMattes schrieb:

    Kennt eine(r) von Euch eigentlich eine Quelle, in der sich Apple einmal zu diesem Thema verbindlich äußert? Streng genommen müsste ja eigentlich jeder Entwickler das "Krypto-Häkchen" bei Einreichen eines Updates setzen: Schliesslich ist der Code mittels kryptographischer Methoden signiert worden.


    Der erstellte App ist nur signiert, damit Apple sieht, dass diese von dir kommt. Nach dem Upload wird deine Signatur wohl entfernt und durch eine von Apple ersetzt. Darüber könnend die Geräte dann feststellen, dass die App aus dem Store kommt. In diesem Fall ist es also an Apple eine passende ERN zu haben. Nur wenn die App selber kryptographisch aktiv wird braucht diese selbst eine ERN. Warum sollte sich Apple die Mühe machen das zu erklären. Auf den passenden Behördenseiten ist doch alles in allerbestem Fachchinesisch erklärt. Apple würde höchstens Gefahr laufen was falsches zu sagen uns sich damit selber haftbar zu machen.

    MyMattes schrieb:

    Oder wie sieht es bei Verwendung von NSURLConnection, um eine HTTPS-Verbindung aufzubauen ... Top oder Flop? Oder ... oder ... oder ...


    HTTPS ist meines Wissens ein Fall der eine Genehmigung braucht. Als Quelle habe ich aber auch nichts offizielles sondern nur eine Reihe von Entwicklerseiten die sich damit beschäftigt haben. Und natürlich die Behördenseite die quasi alles unter Genehemigungspflicht stellt.

    MyMattes schrieb:

    Ich finde, hier wird man ganz schön im Regen stehen gelassen.


    Klar, aber das ist doch quasi so üblich. Sinnvolle Erklärungen zu den Steuerthemen gibt es doch z.B. auch nicht. Klar wäre das ein super Service für die Entwickler. Aber hey, die liefern ihre Apps doch auch ohne das Apple sich hierfür zusätzliche Arbeit machen muss...
  • Wir haben es mal für eine Mac-Anwendung gemacht und das war ein ganz schöner Scheiß. Zum Glück nicht ich(*), sondern ein "native english speaker", ansonsten hätte ich ein paar graue Haare mehr oder säße längst in der Psychiatrie in der Abteilung für gescheiterte Apple-Entwickler. Man kommt sich so vor wie Franz Kafkas kaiserlicher Bote <X Was für ein Affentheater!

    schönen Gruß

    gandhi
    (*) Ich kann nur jedem hier empfehlen, sich davor zu drücken. Und wenn's um die Vergabe dieser Aufgabe geht ganz weit weg zu sein. Hintere Mongolei oder so...
  • SteveJ schrieb:

    Frequently Asked Questions: Export Compliance Understanding export compliance laws for apps that contain encryption.

    Danke, das Dokument kannte ich noch nicht, nur den Passus im iTC Developer Guide.

    Na, die Aussage ist ja ziemlich klar: ERN ist auch erforderlich, wenn "​An app uses or accesses only encryption algorithms provided in iOS or Mac OS for its security features". Damit also z. B. auch alles, was SSL spricht. Einen herzlichen Dank an unsere transatlantischen Verbündeten für eine weitere Paranoia.

    Wenn man sich diese Themen so vor Augen führt (inkl. der Verpflichtung, die Rechtmäßigkeit einer App in allen Zielmärkten sicherzustellen), beschleicht einen der Verdacht, dass viele Publisher nach dem Motto "Augen zu und durch" verfahren ... nicht, dass ich das jemandem raten würde.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MyMattes schrieb:

    Wenn man sich diese Themen so vor Augen führt (inkl. der Verpflichtung, die Rechtmäßigkeit einer App in allen Zielmärkten sicherzustellen), beschleicht einen der Verdacht, dass viele Publisher nach dem Motto "Augen zu und durch" verfahren ... nicht, dass ich das jemandem raten würde.


    Viel Spaß beim nächsten USA-Urlaub. Diese organgefarbenen Anzüge machen sich ganz gut, und das Karibik-Klima ist gut für den Teint. ;)
  • Habe es für alle meine Apps gemacht. Hat mich fast ne Woche gedauert. Ob ich alles 100%ig richtig gemacht habe, weiß ich nicht. Würden unsere Apps auf deutschen Servern liegen hätten wir das Problem wohl nicht...
    “I want to see an elephant hunt down a man for the sole purpose of collecting his teeth, while a chorus of typewriters sings songs that praises the bananas for their wisdom, leadership, and their high levels of potassium.” ― Jarod Kintz, I Want