Um Apps unters Volk zu bringen, reicht das pure Entwickeln eines Stücks Software nicht aus. Damit die Software über den Apple AppStore oder den Google PlayStore verteilt werden kann, muss sie zuerst in die USA "gebracht" (übertragen) werden, denn hier stehen die Server der Plattformbetreiber Apple und Google. Wird Ihre App anschließend ausschließlich in den Vereinigten Staaten angeboten, müssen Sie nicht mehr unbedingt weiterlesen. Anders ist es, wenn die App aus den Vereinigten Staaten in ein anderes Land auf der Welt (etwa Deutschland) verteilt/verkauft werden soll, denn hier unterliegt dies der Exportkontrolle der USA.

Die Missachtung geltender Exportkontrollbestimmungen kann zu empfindlichen Strafen führen. So sind in Amerika die Strafen geradezu drakonisch. Hier drohen Freiheitsstrafen bis zu 20 Jahren. Auch Geldstrafen bis zu 1.000.000 Dollar sind pro Verstoß möglich. Das erste Unternehmen, das vom Bureau of Industry and Security (BIS) verklagt wurde, war 2014 die Intel-Tochter Wind River Systems. Die - laut BIS-Aussage - noch milde Strafe von 750.000 Dollar wurde von vielen Anwälten als Exempel gesehen, da Wind River Systems Software nach China, Hongkong und Russland geliefert hat.

Wozu Kryptographie?

Kritisch ist das Thema US-Exportkontrolle wegen der eingesetzten Verschlüsselungstechnik. Kryptographie wird in Apps verwendet, um Informationsinhalte unlesbar zu machen, Modifikationen zu verhindern oder den unerlaubten Gebrauch der Daten zu unterbinden. Der Entwickler begibt sich damit jedoch in ein Spannungsfeld. Auf der einen Seite stehen die rechtlichen Vorgaben und Anforderungen der Staaten, die zum Zwecke der Strafverfolgung auf verschlüsselte Inhalte zugreifen wollen. Auf der anderen Seite will der Entwickler eine sichere Verschlüsselung gewährleisten, um die Anwender vor Überwachung durch Dritte zu schützen.

Technisch kann bei der Verschlüsselung zwischen symmetrischen (z.B. AES oder 3DES) und asymmetrischen Verfahren (z.B. RSA) unterschieden werden. Im alltäglichen Umgang begegnen viele Anwender einer Kombination aus beiden Verfahren. So hilft im verschlüsselten Internet-Verkehr RSA beim Schlüsselaustausch und AES 256 beispielsweise bei der Übertragung der zu verschlüsselnden Daten.

Wie steht es um die App-Exportbeschränkung in den USA?

Um die Thematik in diesem Artikel etwas einfacher zu erläutern, gehen wir davon aus, dass eine App in Deutschland entwickelt wurde und aus den Vereinigten Staaten über den PlayStore von Google oder den AppStore von Apple bereitgestellt und verteilt werden soll. Für jedes Produkt, das Verschlüsselungskomponenten beinhaltet, muss der Entwickler unter Umständen eine Verschlüsselungsregistrierung, einen Klassifizierungsantrag und/oder einen Selbstklassifizierungsbericht einreichen.

In Amerika besteht, auch wenn die Kryptographie-Exportbeschränkungen vom Verteidigungsministerium aus dem militärischen Umfeld dem Wirtschaftsministerium übergeben wurden, weiterhin eine Exportbeschränkung auf Lösungen mit maximal 64-Bit-Verschlüsselung (symmetrisches Verschlüsselungsverfahren), beziehungsweise 768 Bit (Public-Key, asymmetrisches Verschlüsselungsverfahren) oder 128 Bit für Elliptische-Kurven-Kryptografie. Alle kommerziellen Produkte, die eine stärkere Verschlüsselung anwenden, müssen gemeldet werden. Die hier zuständige Behörde ist das BIS (US Bureau of Industry and Security). Die US-Exportkontrollen hängen also davon ab, ob die in einer App genutzte Verschlüsselung für den Datentransfer (SSL) oder die Datenhaltung verwendet wird.

Dieser Prozess scheint für viele App-Entwickler ein verworrenes Unterfangen zu sein. So weist Google seine Entwickler lediglich darauf hin, dass es gegebenenfalls "Anforderungen" gibt, die sie juristisch erfüllen müssen - wo diese stehen, verrät Google jedoch nicht.

Bei Apple sieht die Sachlage anders aus. Entwickler gelangen beim Bereitstellen ihrer Software zu einem Fragenkatalog, der sie zumindest bei den ersten Schritten begleitet.

Dieser Dialog besagt, dass eine App, die bei der Datenhaltung und/oder der Datenkommunikation auf Verschlüsselung setzt, die das jeweilige iOS-Betriebssystem als Basis mitliefert, entsprechend klassifizieren muss.

War es bis September 2016 noch generell notwendig, eine Encryption Registration Number (ERN) zu beantragen, entfällt dies, wenn App-Entwickler nur Standards aus dem jeweiligen Betriebssystem verwenden.

Allerdings müssen Apps die Verwendung von Kryptographie ausweisen. Das Gleiche gilt auch für die "Self Classification" - die eigene Attestierung - einer App. Verwenden Sie eine ausgefeilte - selbst entwickelte - Kryptographie, kommen Sie um die Beantragung und Registrierung einer eigenen ERN nicht herum.

Wie erfolgt die Klassifizierung einer App ?

Der so zu erstellende jährliche Selbstklassifizierungsbericht für Apps, die während eines Kalenderjahres exportiert werden, muss beim BIS (crypt-Supp8@bis.doc.gov und crypt@bis.doc.gov) und dem ENC Encryption Request Coordinator (enc@nsa.gov) bis spätestens 1. Februar des folgenden Jahres eingehen.

Dazu muss gemäß der Angaben des BIS der Entwickler eine E-Mail an die besagten Stellen senden. Diese enthält den Selbstklassifizierungsbericht in Form einer CSV-Datei (Comma Separated Values) als Dateianhang. Der E-Mail-Betreff lautet dabei "Self-Classification Report for Encryption Items" und der E-Mail-Text muss leer bleiben. Lediglich der Selbstklassifizierungsbericht im .csv-Dateiformat darf angehängt werden.

Die Selbstklassifizierung als CSV unterliegt dabei einem festen Aufbau.

Der PRODUCT NAME entspricht dem App Namen. Das Feld MODEL NUMBER können Sie mit "NONE" oder "N/A" deklarieren. Eine Versionsnummer der App müssen Sie nach unserem Kenntnisstand hier nicht pflegen. Als MANUFACTURER trägt sich der Entwickler mit seinem Firmennamen ein. Gibt es keinen Firmennamen, können Sie hier "NONE" oder "N/A" eintragen. Bei dem Feld ECCN bedarf es etwas Recherche und Sachkenntnis zur App selbst, denn bei dieser Klassifizierung stehen verschiedene Optionen zur Verfügung.

Grundsätzlich sind ECCN Nummern immer identisch aufgebaut. Sie weisen einen fünfstelligen Aufbau auf. Das Format entspricht dabei immer diesem Beispiel: ZBZZZ (Z=Zahl, B=Buchstabe).

Die erste Stelle gibt dabei die Kategorie des beschriebenen Gutes an:

• 0 : Kerntechnische Materialien, Anlagen und Ausrüstung

• 1 : Besondere Werkstoffe und Materialien und Ausrüstung

• 2 : Werkstoffbearbeitung

• 3 : Allgemeine Elektronik

• 4 : Rechner

• 5 : Telekommunikation und Informationssicherheit

• 6 : Sensoren und Laser

• 7 : Luftfahrtelektronik und Navigation

• 8 : Meeres- und Schiffstechnik

• 9 : Luftfahrt, Raumfahrt und Antriebe

Die zweite Stelle gibt die Gattung an:

• A : Systeme, Ausrüstung und Bestandteile

• B : Prüf-, Test- und Herstellungseinrichtungen

• C : Werkstoffe und Materialien

• D : Datenverarbeitungsprogramme (Apps)

• E : Technologie

Die letzten drei Stellen geben spezifische Auskunft über die Deklarierung:

• 001 - 099: Wassenaar-Arrangement-Güter

• 101 - 199: Raketentechnologie

• 201 - 299: Nuklearwaffen

• 301 - 399: biologische Waffen

• 500 - 899: reservierte Nummern in den Vereinigten Staaten. Die 500er Serie beschreibt beispielsweise weltraumgeeignete Güter oder die 600er Serie Rüstungsgüter

• 900 - 999: Güter, die unter nationale Kontrollgründe fallen (z.B. Terrorismus-Abwehr, Verbrechenskontrolle)

Handelt es sich um Apps ohne kryptographische Bestandteile, werden sie als EAR99 klassifiziert und müssen nicht über die Selbstauskunft gemeldet werden. Apps für den Massenmarkt, deren Schlüssellänge nicht länger ist als 64 Bit (symmetrisch), beziehungsweise 768 Bit(asymmetrisch) oder 128 Bit (elliptische Kurven), werden als 5D992 klassifiziert.

Apps, die nicht für den Massenmarkt erstellt werden, deren Schlüssellänge länger ist als 56 Bit bei symmetrischer, beziehungsweise 512 Bit bei asymmetrischer Verschlüsselung oder 112 Bit bei elliptischen Kurven entspricht, werden als 5D002 klassifiziert.

Apps, die unter 5D992 fallen, werden nur aus Anti-Terrorismus-Gründen kontrolliert. Sie dürfen überall hin exportiert werden, außer nach Nordkorea, Sudan, Syrien, Iran oder Kuba. Apps hingegen, die unter 5D002 erfasst werden, unterliegen wesentlich strengeren Kontrollen. Zusätzlich zu der Kontrolle für AT wird 5D002 auch für EI (Encryption Item) und NS (National Security) relevant. Software mit dieser Klassifizierung muss bei der Bereitstellung zum Download in den Ländern eingeschränkt (z.B. wegen Embargo) werden. Dazu können Sie sich hier informieren.

Erfolgte bereits eine Registrierung der verwendeten Kryptographie-Produkte eines Herstellers (etwa Apple), berechtigt dies den Hersteller eines anderen Produktes (wie den Entwickler einer App) zum Export mit identischer Klassifizierung. Eine Bedingung für diese Genehmigung ist, dass der Hersteller jährlich einen Selbstklassifizierungsbericht für die relevanten Verschlüsselungselemente vorlegen muss. Zumindest für den Hersteller Apple konnten wir entsprechende Hinweise im Internet finden.

Verwendet Ihre App zusätzliche Bibliotheken, müssen Sie auch hier prüfen, ob eine "stärkere" Klassifizierung notwendig ist. Hier einige Beispiele für Angaben diverser Hersteller:

• Oracle oder

• Microsoft.

Liegen die Angaben nicht vor, müssen diese angefragt oder gewissenhaft selbst ermittelt werden.

Der AUTHORIZATION TYPE beschreibt vereinfacht ausgedrückt, in welchem Umfeld Sie die Verschlüsselung einsetzen. Sie können Ihre App hier entweder als ENC (§ 740.17(b)) oder als "Massenmarkt" (§ 742.15(b)) bezeichnen. Als ITEM TYPE können Sie "Mobility and mobile applications n.e.s" hinterlegen. Als SUBMITTER NAME müssen Sie den Vor- und Nachnamen der verantwortlichen Person für den Export (der Entwickler) hinterlegen. Die Felder TELEPHONE NUMBER, E-MAIL ADDRESS und MAILING ADDRESS enthalten die Kontaktinformationen zu der der unter MANUFACTURER gepflegten Firma. Ist keine Firma gepflegt, handelt es sich um die Adresse des SUBMITTER NAME.

Das Feld NON-U.S. COMPONENTS beantwortet die Frage, ob eine App Verschlüsselungskomponenten, die von nicht-amerikanischen Quellen oder Anbietern hergestellt oder geliefert werden. Tragen Sie hier entsprechend "YES" oder "NO" ein. Wenn Sie in dem Feld "YES" eingetragen haben, müssen Sie unter NON-U.S. MANUFACTURING LOCATIONS die nicht US-amerikanischen Produktionsstandorte mit Stadt und Land aufführen (250 Zeichen oder weniger). Sind keine Standorte aufzuführen, tragen Sie "NONE" oder "N/A" ein.

Wenn Sie diese Informationen anwenden, kann eine CSV-Datei beispielsweise wie folgt aussehen:

PRODUCT NAME, MODEL NUMBER, MANUFACTURER, ECCN, AUTHORIZATION TYPE, ITEM TYPE, SUBMITTER NAME, TELEPHONE NUMBER, E-MAIL ADDRESS, MAILING ADDRESS, NON-U.S. COMPONENTS, NON-U.S. MANUFACTURING LOCATIONS

SecureContact Business, N/A, MobileBox - App Consulting UG, 5D992, MMKT, Mobility and mobile applications n.e.s, Mark Zimmermann, +4915152458996, info@mobilebox-consulting.de, Augustenburgstrasse 88 76229 Karlsruhe Germany, YES, Karlsruhe Germany

Wird eine App nicht aktualisiert, muss eine E-Mail gesendet werden, in der mitgeteilt wird, dass sich seit dem letzten Bericht nichts geändert hat. Alternativ kann auch eine Kopie des zuletzt eingereichten Selbstklassifizierungsbericht eingereicht werden.