# Gerätesicherheit (/de/in-store/security/device_security) Das Tapaya Accept SDK verwandelt handelsübliche Verbrauchergeräte (COTS, consumer off-the-shelf) in sichere Zahlungsterminals. Da diese Geräte keine dedizierte Zahlungshardware sind, setzt das SDK strenge Sicherheitsmaßnahmen um, um Bedrohungen abzuwehren und die Einhaltung der PCI-Standards zu gewährleisten. ## Geräteattestierung [#device-attestation] Um eine sichere Zahlungsumgebung zu gewährleisten, prüft das SDK den Zustand des Host-Geräts kontinuierlich. Erkennt es eine Sicherheitsverletzung, verweigert das SDK die Initialisierung oder die Verarbeitung von Transaktionen. ### Root- und Jailbreak-Erkennung [#root-and-jailbreak-detection] Das SDK überwacht die Umgebung auf Anzeichen einer Rechteausweitung. Dazu gehört die Erkennung von Root-Binärdateien oder Frameworks zur Rechteverwaltung wie Magisk oder SuperSU. Außerdem prüft es auf unberechtigten Lese- oder Schreibzugriff auf geschützte Systemverzeichnisse. Darüber hinaus erkennt es nicht standardmäßige Betriebssystem-Builds, einschließlich Custom ROMs oder veränderter Kernel-Signaturen. ### Debugging-Erkennung [#debugging-detection] Um Reverse Engineering und unberechtigte Tests zu verhindern, erkennt das SDK, ob ein Debugger an die Anwendung angehängt ist, und prüft, ob es auf einem physischen Gerät läuft. Die Ausführung in Emulatoren oder virtuellen Umgebungen ist eingeschränkt. ### Google Play Integrity API [#google-play-integrity-api] Unter Android nutzt das SDK die **Play Integrity API**, um zu validieren, dass das Geräte-Binary von Google erkannt wird und nicht manipuliert wurde. ## Anwendungssicherheit [#application-security] ### Code-Obfuskation [#code-obfuscation] Das Tapaya Accept SDK verwendet fortschrittliche Obfuskationstechniken, um das Risiko von Reverse Engineering zu verringern. Codesymbole werden in nichtssagende Bezeichner umbenannt, die Programmlogik wird gezielt verschleiert, und sensible Zeichenketten oder eingebettete Schlüssel werden verschlüsselt. ### Manipulationsschutz [#anti-tampering] Das SDK prüft zur Laufzeit seine eigene Integrität. Es prüft die digitale Signatur der Anwendung und der SDK-Bibliotheken. Wurde das APK von Dritten verändert oder neu verpackt, startet das SDK nicht. ## Datenschutz [#data-protection] ### Ende-zu-Ende-Verschlüsselung (E2EE) [#end-to-end-encryption-e2ee] Kartendaten werden verschlüsselt, sobald sie vom NFC-Controller gelesen werden. Es kommt starke Verschlüsselung nach Branchenstandard zum Einsatz, und die Entschlüsselungsschlüssel werden ausschließlich in sicheren HSMs gespeichert. Das Mobilgerät hat niemals Zugriff auf unverschlüsselte Kartendaten. ### Sichere Eingabe [#secure-input] Bei PIN-basierten Transaktionen sorgt das SDK für eine sichere Eingabe. Der PIN-Bildschirm ist gegen Overlay-Angriffe geschützt, das Tastenlayout wird zufällig angeordnet, und bei jeder Toucheingabe wird geprüft, ob sie vom physischen Gerät stammt. ## Überwachung der Umgebung [#environment-monitoring] ### Verhinderung von Bildschirmaufnahmen [#screen-recording-prevention] Zum Schutz sensibler Daten blockiert das SDK Screenshots, Bildschirmaufnahmen und Bildschirmfreigaben, indem es auf dem Gerät sichere Anzeigeeinstellungen erzwingt. ### Bedienungshilfen [#accessibility-services] Schädliche Apps missbrauchen häufig Bedienungshilfen (Accessibility Services), um Bildschirminhalte auszulesen oder Eingaben einzuschleusen. Das SDK erkennt aktive Bedienungshilfen. Standarddienste für sehbehinderte Benutzer (wie TalkBack) lässt es zu, unbekannte oder verdächtige Dienste kann es während des Zahlungsablaufs jedoch blockieren. ## Attestierung und Überwachung in Ihrer App [#attestation-and-monitoring-in-your-app] Attestierung und Überwachung sind keine Komponente, die Sie installieren. Sie sind im Tapaya Accept SDK und in der Plugin-App Tapaya Terminal enthalten, starten mit `Accept.initialize()` und laufen, solange das SDK aktiv ist. Es gibt kein Konfigurations-Flag, keine Möglichkeit zur Deaktivierung und keinen Modus, der sie lockert. Beide Hälften müssen unabhängig voneinander bestehen. Ihre App hostet das SDK, und das SDK übergibt jede Kartenzahlung an Tapaya Terminal, das sich separat selbst attestiert. Ein Gerät, das die Prüfungen der einen Hälfte besteht, die der anderen aber nicht, kann keine Zahlungen annehmen. ### Attestierung in Ihre App integrieren [#integrating-attestation-into-your-app] | Pflicht | So sieht es im Code aus | | :----------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | | Einmal und frühzeitig initialisieren | `Accept.initialize(context, isProduction = true)` in Ihrer `Application`-Klasse. | | Die tatsächliche Umgebung angeben | `isProduction` richtet sich nach Ihrem Build-Typ, niemals nach einem aus Bequemlichkeit fest codierten Wert. | | Tapaya Terminal installiert und aktiviert halten | Prüfen Sie vor der Annahme einer Zahlung `Accept.plugin.isInstalled()` und rufen Sie dann `Accept.plugin.activateTerminal()` auf. | | Eine Verweigerung als endgültig behandeln | Melden Sie sie dem Händler und brechen Sie ab. Versuchen Sie es nicht erneut und weichen Sie nicht auf einen anderen Codepfad aus. | Die vollständige API hinter jedem dieser Punkte finden Sie unter [Integration des mobilen SDK](../integration/sdk_integration). ### Bereitstellung in einer produktionsreifen Konfiguration [#deploying-in-a-production-ready-configuration] Ein Produktions-Build darf nicht debugfähig sein, darf nicht loggen und darf die Transportsicherheit nicht schwächen. Das SDK erzwingt das meiste davon selbst: Ein debugfähiger Build oder ein angehängter Debugger verhindert seine Initialisierung vollständig. | Einstellung | Entwicklung | Produktion | | :------------------------------------ | :--------------------------------------------------------------- | :----------------------------------------------------------------------------- | | `android:debuggable` | `true` | `false` | | `Accept.initialize(isProduction = …)` | `false` | `true` | | `Accept.setDebugLoggingEnabled(…)` | `true` | `false` | | Signaturschlüssel | Debug-Keystore | Release-Keystore | | R8 / ProGuard | aus | an, mit unveränderten Consumer-Regeln des SDK | | Netzwerksicherheitskonfiguration | darf vom Benutzer installierten Zertifizierungsstellen vertrauen | kein Vertrauen in Benutzer-Zertifizierungsstellen, keine Umgehung des Pinnings | | USB-Debugging auf dem Gerät | an | aus | Steuern Sie die Umgebung über den Build, statt sie vor einem Release von Hand anzupassen: ```kotlin Accept.initialize(context = this, isProduction = !BuildConfig.DEBUG) Accept.setDebugLoggingEnabled(BuildConfig.DEBUG) ``` Ein Build, der mit aktiviertem Debugging, eingeschaltetem Debug-Logging oder umgangenem Certificate Pinning ausgeliefert wird, liegt außerhalb der Konfiguration, für die Tapaya Accept zertifiziert ist, unabhängig davon, ob er weiterhin Zahlungen verarbeitet. Prüfen Sie vor jedem Produktions-Release jede Zeile der obigen Tabelle. ### Voraussetzungen der Plattform [#platform-preconditions] Jede der oben genannten Prüfungen hängt von einer Fähigkeit des Host-Geräts ab. Die Seite [Unterstützte Geräte](../getting-started/supported_devices#android-requirements) führt jede Anforderung auf, erklärt, warum die Attestierung sie benötigt und was passiert, wenn sie fehlt. Zwei davon bestimmen die Auswahl der Hardware: * **Android 11 ist eine feste Untergrenze.** Auf Geräten mit einer älteren Version läuft das SDK überhaupt nicht. Mehrere dedizierte SoftPOS-Modelle werden noch mit Android 7 bis 9 ohne Update-Möglichkeit ausgeliefert, prüfen Sie daher die Betriebssystemversion des konkreten Geräts statt der Modellreihe. * **Google Mobile Services sind optional.** Sind GMS vorhanden, ergänzt das SDK seine eigenen Prüfungen um das Ergebnis der [Play Integrity API](#google-play-integrity-api). Dedizierte Terminals, die ohne GMS ausgeliefert werden, wie es bei Herstellern wie Sunmi und iMin üblich ist, werden vollständig unterstützt. ### Wenn eine Prüfung fehlschlägt [#when-a-check-fails] Eine fehlgeschlagene Prüfung ist für das betreffende Gerät endgültig und kein vorübergehender Fehler, bei dem ein erneuter Versuch sinnvoll wäre. Das SDK verweigert die Initialisierung oder verweigert die Verarbeitung einer Transaktion, wenn die Verletzung während einer Session auftritt. Nichts in Ihrer Integration kann das außer Kraft setzen, und der Versuch, es zu umgehen, führt dazu, dass Ihre Bereitstellung außerhalb ihrer zertifizierten Konfiguration liegt. Behandeln Sie dies wie einen nicht behebbaren Gerätefehler: Teilen Sie dem Händler mit, dass das Gerät keine Zahlungen annehmen kann, und verweisen Sie ihn an den Support. Wiederholen Sie den Versuch nicht in einer Schleife und weichen Sie nicht auf einen anderen Zahlungsweg aus. ## Verantwortlichkeiten des Entwicklers [#developer-responsibilities] Auch wenn das SDK die Hauptarbeit übernimmt, müssen Sie als Integrator Folgendes sicherstellen: 1. **Sicherheitswarnungen nicht deaktivieren:** Versuchen Sie in Produktions-Builds nicht, SSL Pinning oder die Root-Erkennung zu umgehen. 2. **SDK aktuell halten:** Sicherheitspatches werden regelmäßig veröffentlicht. Stellen Sie sicher, dass Ihre App die neueste Version des Tapaya Accept SDK verwendet. 3. **Ihre App obfuskieren:** Wenden Sie ProGuard oder R8 auf Ihren eigenen Anwendungscode an, um zu verhindern, dass API-Schlüssel oder die Logik, die mit dem SDK interagiert, offengelegt werden. ```kotlin title="proguard-rules.pro" # The Tapaya Accept SDK includes its own consumer rules, but ensure you do not strip them -keep class com.tapaya.** { *; } ``` ## Sicherheitsvorfall melden [#reporting-a-security-incident] Wenn Sie eine Sicherheitslücke entdecken oder einen Sicherheitsvorfall im Zusammenhang mit dem Tapaya Accept SDK oder Ihrer Integration vermuten, melden Sie dies vertraulich wie unter [Kontakte](/support/contacts#security-issues) beschrieben. Geben Sie, sofern zutreffend, die betroffene SDK-Version und Informationen zum Gerät an.