> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/nfc-wallet-sdk-android/es/security-and-privacy/security-guidance.md). # Guía de seguridad ## Resumen Utilice esta guía de seguridad al crear y lanzar un Android **aplicación de billetera digital** que integra el SDK de billetera NFC. Esta guía es un conjunto de directrices de seguridad que debe aplicar antes del lanzamiento. ## Directrices generales de seguridad ### Use la última versión del SDK de billetera NFC Use la última versión del SDK de billetera NFC. Incluye las últimas actualizaciones y correcciones de seguridad. ### Use la compilación Release del SDK de billetera NFC Antes de publicar en Google Play Store, configure la aplicación de billetera digital para usar la `Release` compilación. {% hint style="warning" %} El `Dev` La variante de SDK no está permitida en el entorno de producción. {% endhint %} ### Eliminar símbolos de depuración No publique con símbolos de depuración. Esta práctica aumenta la complejidad de los esfuerzos de ingeniería inversa y evita la identificación fácil de variables, estructuras y lógica sensibles. ### Prevenir fugas de datos sensibles Borre los datos sensibles de la interfaz de usuario antes de que la aplicación pase a segundo plano. Cifre o borre los datos hasta que la aplicación vuelva al primer plano. Evite registrar información sensible. ### Use ofuscación de código Use ofuscación para aumentar el costo de la ingeniería inversa. ### Asegurar la comunicación de red Use HTTPS para todas las llamadas de red al backend de la billetera digital. Evite certificados autofirmados. Si implementa fijación de certificados, siga estas directrices: * Haga coincidir el nombre de host con el certificado leaf (hoja). * Valide la cadena completa de certificados contra el almacén de confianza del sistema. * Rechace certificados caducados. * Fije el hash SHA-256 de la CA raíz o del certificado leaf. Si envía datos confidenciales que contienen información de identificación personal (PII), agregue cifrado y autenticación a nivel de aplicación cuando sea necesario. ### Agregar protección RASP Use una solución comercial de Runtime Application Self Protection ([RASP](https://en.wikipedia.org/wiki/Runtime_application_self-protection)). Detectar y responder a: * Root o jailbreak. * Depuración. * Hooking. * Manipulación de la aplicación. * Ejecución en emulador. ### Registro (Logging) Evite escribir datos sensibles en los registros del dispositivo. Use flags de compilación para excluir registros de depuración de las compilaciones del entorno de producción. En Android, los registros son un recurso compartido que es accesible con el `READ_LOGS` permiso, y el registro inapropiado de información sensible del usuario puede conducir a fugas de datos no intencionales a otras aplicaciones. ### Adoptar prácticas de codificación seguras Aplique prácticas de codificación segura durante el desarrollo. Por ejemplo, debería: * realizar validación de entradas. * gestionar adecuadamente la memoria. * usar funciones C seguras. * evitar el uso de contenedores inmutables para almacenar datos sensibles. Para una lista de verificación básica, vea OWASP [Prácticas de codificación segura](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide). Estas prácticas se pueden aplicar mediante herramientas de análisis estático de código como PMD o HP Fortify. ### Realizar auditorías y pruebas de penetración Realice auditorías de arquitectura y de código, además de pruebas de penetración, para identificar vulnerabilidades y evaluar la postura general de seguridad de la aplicación. ### Evaluar la resistencia de la seguridad de la aplicación Consulte el OWASP MASVS (Mobile Application Security Verification Standard) en [OWASP MASVS](https://github.com/OWASP/owasp-masvs). Este es el punto de referencia de requisitos de seguridad para aplicaciones móviles. Se recomienda encarecidamente utilizar la checklist OWASP MSTG [lista de verificación](https://github.com/OWASP/owasp-mastg/releases/latest) para evaluar el estado de seguridad de su aplicación. ## Directrices de seguridad para desarrolladores Android Use la guía de seguridad de Android para recomendaciones detalladas de defensa en profundidad antes del lanzamiento. Revise estos temas: * [Protección a nivel de aplicación](#application-level-protection) * [Protección de datos](#data-protection) * [Autenticación](#authentication) * [Directrices de criptografía](#cryptography-guidelines) * [Endurecimiento de la aplicación](#application-hardening) * [Codificación segura](#secure-coding) {% hint style="info" %} Use la lista de verificación de seguridad base de Android como referencia adicional a esta guía: [Lista de verificación de seguridad de Android](https://developer.android.com/training/articles/security-tips). {% endhint %} ### Protección a nivel de aplicación #### Verifique el instalador de su aplicación Verifique el nombre del paquete instalador de su aplicación de billetera digital en tiempo de ejecución. Confíe solo en las instalaciones desde Google Play, que usa `com.android.vending`. Para prevenir la distribución por canales secundarios o instalaciones no autorizadas desde fuentes de terceros. #### Hacer cumplir actualizaciones de seguridad (forzar actualización de la aplicación) Asegure una actualización forzada de la aplicación en caso de correcciones de seguridad. * Bloquee el acceso al servicio cuando la versión instalada esté por debajo de la versión mínima permitida. #### Almacene recursos en el almacenamiento interno Mantenga su **aplicación de billetera digital** y sus recursos en el almacenamiento interno. Esto reduce el riesgo de un ataque man-in-the-disk (MITD). En ataques MITD, un atacante puede modificar o manipular archivos almacenados en el almacenamiento externo. La aplicación no debe permitir que se traslade al almacenamiento externo usando el `android:installLocation` atributo del manifiesto. #### Compatibilidad con versiones del SO soportadas por el SDK Ejecute su **aplicación de billetera digital** solo en versiones del SO compatibles con el SDK de billetera NFC. Esto reduce problemas funcionales y brechas de seguridad en dispositivos antiguos. También mejora la **usuario final** experiencia. #### Requerir bloqueo de pantalla en el dispositivo Requiera que el dispositivo tenga un bloqueo de pantalla. Use un PIN, patrón o contraseña. Bloquee flujos sensibles si no se ha establecido un bloqueo de pantalla. ```java KeyguardManager keyguardManager = (KeyguardManager) context.getSystemService(Context.KEYGUARD_SERVICE); boolean isDeviceSecure = keyguardManager != null && keyguardManager.isDeviceSecure(); if (!isDeviceSecure) { // Bloquear el flujo. // Solicitar al usuario final que active un bloqueo de pantalla en la Configuración de Android. } ``` #### Prevenir permisos excesivos Declare solo los permisos de Android requeridos para su **aplicación de billetera digital**. Los permisos innecesarios amplían la superficie de ataque y pueden exponer datos privilegiados. #### Restringir componentes exportados Las aplicaciones Android se construyen a partir de componentes: * Actividades * Servicios * Receptores de broadcast * Proveedores de contenido Considere: * La comunicación entre aplicaciones como arriesgada. * Cada componente exportado como un punto de entrada público hacia su **aplicación de billetera digital,** aumentando así su exposición a riesgos y ataques. Recomendamos diseñar su aplicación * con solo una actividad principal accesible públicamente. * Todos los demás componentes deberían tener explícitamente el atributo `export=false`. Para que los componentes sean públicos, considere protegerlos con permisos personalizados. #### Deshabilitar la depuración en compilaciones de release Asegúrese de que la `producción` compilación de su **aplicación de billetera digital** no sea depurable. Usted debe: * Establecer `android:debuggable="false"` en el `` elemento en `AndroidManifest.xml`. * Y asegúrese de que su APK final no sea depurable. Para verificar su APK final: 1. Ejecute: ```bash aapt dump xmltree AndroidManifest.xml ``` 2. En la salida, localice el `` elemento. Confirme que `android:debuggable` está establecido en `0x0`. Automatice esta verificación como parte de su canalización CI. #### Evaluar enlaces de aplicación y enlaces profundos Los enlaces profundos y los enlaces de aplicación pueden aumentar la superficie de ataque de la aplicación. Pueden introducir riesgos como el secuestro de enlaces y la exposición no intencionada de funcionalidades sensibles. El comportamiento varía según la versión de Android: * Antes de Android 12 (nivel de API 31), si la aplicación incluye enlaces no verificables, el sistema puede no verificar todos los Android App Links para esa aplicación. * A partir de Android 12 (nivel de API 31), la aplicación se beneficia de una superficie de ataque reducida. A menos que la aplicación destino esté aprobada para el dominio específico en el intent web, el intent web se resolverá en la aplicación de navegador predeterminada del usuario final. Enumere todos los enlaces profundos. Verifique la asociación correcta del sitio web. Pruebe cada operación expuesta a través de enlaces profundos y enlaces de aplicación. Siempre valide todos los datos de entrada. Trate todas las entradas como no confiables. La validación asegura que la aplicación procese solo los datos que espera. #### Prevenir capturas de pantalla y vistas previas de la aplicación Establecer `FLAG_SECURE` en cualquier actividad que muestre datos sensibles. Esto previene la fuga de datos sensibles a través de capturas de pantalla en primer plano. Agregue la bandera en `Activity.onCreate()` antes de renderizar la interfaz de usuario: ```java @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); getWindow().addFlags(WindowManager.LayoutParams.FLAG_SECURE); } ``` También borre la información sensible en sus actividades en `onPause()` método. #### Firmado correcto de la aplicación Firme su APK de release con: * APK Signature Scheme v1 y v2 para amplia compatibilidad con Android. * APK Signature Scheme v3 al apuntar a Android 9 (nivel de API 28) y posteriores. {% hint style="info" %} Mantenga la clave de firma del APK bajo su control. No la comparta. {% endhint %} Verifique firmas con `apksigner` desde Android SDK Build Tools: ```bash $ apksigner verify --verbose Desktop/example.apk Verificado usando el esquema v1 (firma JAR): true Verificado usando el esquema v2 (APK Signature Scheme v2): true Verificado usando el esquema v3 (APK Signature Scheme v3): true Número de firmantes: 1 ``` #### Prevenir la copia de seguridad de los datos de la aplicación Desactive la copia de seguridad y restauración de Android para su **aplicación de billetera digital**. Establecer `android:allowBackup="false"` en el `` elemento en `AndroidManifest.xml`. ```xml ``` Por defecto, `android:allowBackup` es `true`. Esto permite que el SO haga copia de seguridad y restaure los datos de la aplicación. Esto puede tener implicaciones de seguridad. La función de copia de seguridad también puede permitir que un usuario final copie los datos de la aplicación cuando la depuración USB está habilitada. Una vez exportados, los datos pueden ser inspeccionados fuera del sandbox de la aplicación. #### Limitar la accesibilidad en pantallas sensibles Los servicios de accesibilidad de Android pueden leer el contenido de la interfaz de usuario y desencadenar acciones. Esto es esencial para usuarios con discapacidades. También puede ser abusado por malware para capturar datos sensibles. Decida, por pantalla, si los servicios de accesibilidad deben acceder al contenido sensible. Use las técnicas a continuación para reducir la fuga de datos a través de eventos de accesibilidad. {% hint style="warning" %} Bloquear la accesibilidad puede impedir que algunos **usuarios finales** usen su **aplicación de billetera digital**. Aplique estos controles solo en pantallas verdaderamente sensibles. {% endhint %} **Detectar servicios de accesibilidad habilitados** Verifique si algún servicio de accesibilidad está habilitado. Si es necesario, limite flujos específicos cuando los servicios estén habilitados. **Lista de permitidos para servicios de accesibilidad** Use las API de Android para listar los servicios habilitados. Mantenga una lista de permitidos o bloqueados según su política de riesgo. Si un servicio no permitido está habilitado, advierta al **usuario final** o bloquee la operación. **Bloquear accesibilidad para una vista** Puede deshabilitar la accesibilidad para un subárbol de vista. Esto evita eventos de accesibilidad de la vista y sus hijos. ```java private void disableAccessibilityEvents(View view) { ViewCompat.setImportantForAccessibility( view, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS ); } ``` **Evitar que texto sensible se exponga en eventos de accesibilidad** Por defecto, Android puede mostrar brevemente el último carácter tecleado antes de enmascararlo. Esto puede exponer entradas parciales (por ejemplo, `***1`) a servicios de accesibilidad. Si esto es inaceptable para su modelo de amenaza, enmascare los caracteres inmediatamente. {% code expandable="true" %} ```java private fun hideLastDigit() { transformationMethod = SecureTransformationMethod() } class SecureTransformationMethod : PasswordTransformationMethod() { override fun getTransformation(source: CharSequence?, view: View?): CharSequence { if (source == null) return SecureCharSequence("") return SecureCharSequence(source) } class SecureCharSequence(private val charSequence: CharSequence) : CharSequence { override val length: Int get() = charSequence.length override fun get(index: Int): Char { return 'x' } override fun subSequence(startIndex: Int, endIndex: Int): CharSequence { return SecureCharSequence(charSequence.subSequence(startIndex, endIndex)) } } } ``` {% endcode %} #### Prevenir ataques por superposición Las superposiciones de Android permiten que una aplicación dibuje la interfaz de usuario encima de otra. Esto puede facilitar el phishing y el robo de datos. Es una técnica común en ataques por superposición. Escenario de phishing de ejemplo: Un atacante dibuja una superposición de pantalla completa encima de su **aplicación de billetera digital**. La superposición se hace pasar por una pantalla de inicio de sesión o de PIN. Esto aumenta la probabilidad de robar las credenciales del usuario final. Proteja las pantallas y entradas sensibles. Ejemplos incluyen inicio de sesión, entrada de PIN y aprovisionamiento. **Android 12 (nivel de API 31) y posteriores** Llamar `setHideOverlayWindows(true)` en vistas sensibles. Esto bloquea las superposiciones que no son del sistema para esas vistas. **Android 2.3 (nivel de API 9) a Android 11 (nivel de API 30)** Use filtrado de toques en vistas sensibles. Esto ayuda a detectar toques oscurecidos por superposiciones. Use una o más de estas opciones: * Habilitar `setFilterTouchesWhenObscured(true)` en vistas sensibles. * Sobrescribe `onFilterTouchEventForSecurity()` para rechazar eventos táctiles oscurecidos. * Verifique los eventos táctiles en `onTouch()` y rechace los eventos oscurecidos. {% hint style="warning" %} El filtrado de toques no cubre todas las técnicas de superposición. Algunas superposiciones pueden evitar reenviar eventos táctiles. Trate esto como una defensa en profundidad, no como una solución completa. {% endhint %} Para más detalles, vea [Protección contra ataques de superposición en Android](https://www.guardsquare.com/blog/protecting-against-android-overlay-attacks-guardsquare). #### Use un teclado propietario Evite teclados de terceros para entradas sensibles. Los teclados de terceros pueden capturar lo que un **usuario final** escribe. Use un teclado propietario que esté disponible solo en su **aplicación de billetera digital**. Úselo para PINs, códigos de acceso, contraseñas e información de identificación personal (PII). Si no puede implementar un teclado propietario, use un teclado numérico dedicado para la entrada de códigos. Aleatorice la disposición de las teclas por sesión. Esto reduce el riesgo de observación por encima del hombro. También puede reducir el impacto de algún malware de accesibilidad. ### Protección de datos #### Proteja los datos en tránsito Use TLS 1.2 o TLS 1.3 para todo el tráfico de red entre su **aplicación de billetera digital** y su **backend del emisor**. Configure su **backend del emisor** para usar suites de cifrado fuertes. Además: * Implemente **fijación de certificados** en su **aplicación de billetera digital**. En Android 7.0 (nivel de API 24) y posteriores, use [Configuración de seguridad de red](https://developer.android.com/training/articles/security-config) para fijar (pin) los dominios que llama su aplicación. * Agregue **cifrado y autenticación a nivel de aplicación** además de TLS para proteger cargas sensibles (por ejemplo, información de identificación personal (PII)) entre su **aplicación de billetera digital** y su **backend del emisor**. #### Proteja los datos almacenados Proteja los datos sensibles almacenados en el dispositivo, incluso dentro del sandbox de la aplicación. Suponga que un dispositivo comprometido puede exponer el almacenamiento local al malware. Se recomienda cifrar y proteger la integridad de los datos sensibles en reposo, usando claves vinculadas al dispositivo, y debe requerir la autenticación del usuario final antes de permitir el acceso. Para cifrar todos los datos sensibles en reposo, la aplicación puede usar * AndroidX Security Crypto `EncryptedSharedPreferences` para datos clave-valor. * AndroidX Security Crypto `EncryptedFile` para archivos. Para más detalles, vea la orientación de Android sobre [almacenamiento de datos](https://developer.android.com/topic/security/data). ### Autenticación #### Admitir autenticación biométrica El **aplicación de billetera digital** debe admitir la autenticación biométrica para la autenticación del usuario final. Proporcione una alternativa de credenciales del dispositivo (keyguard) cuando las biométricas no estén disponibles. Use Android Keystore con `BiometricPrompt` objetos criptográficos cuando sea posible. Esto vincula las claves al dispositivo y detecta cambios en el registro biométrico. #### Imponer autenticación multifactor Implemente autenticación multifactor (MFA) para operaciones sensibles en su **aplicación de billetera digital**. La MFA añade protección al requerir más de un factor de autenticación antes del acceso. Esto reduce el riesgo de acceso no autorizado si un factor queda comprometido. ### Directrices de criptografía #### Mantenga el proveedor de seguridad de Google Play actualizado Usa el [Proveedor de seguridad de Google Play services](https://developer.android.com/training/articles/security-gms-provider) para recibir correcciones de criptografía y TLS en dispositivos que no reciben actualizaciones oportunas del sistema operativo. El SDK de NFC Wallet no instala, actualiza ni solicita este proveedor. Su **aplicación de billetera digital** es responsable de asegurar que el proveedor de seguridad de Google Play services esté instalado y actualizado en el **dispositivo** del usuario final. #### Use un generador de números aleatorios seguro Use `java.security.SecureRandom` para toda aleatoriedad sensible para la seguridad (generar cualquier clave criptográfica sensible o para cualquier generación de datos aleatorios). En Android 10 (nivel de API 29) y posteriores, prefiera `SecureRandom.getInstanceStrong()` cuando requiera la fuente de aleatoriedad más fuerte disponible. ### Endurecimiento de la aplicación #### Detectar dispositivos rooteados Detecte un entorno de dispositivo comprometido (por ejemplo, marcos de trabajo de root y `binarios su` ) antes de inicializar el SDK de NFC Wallet y antes de realizar cualquier operación sensible. Consulte la guía OWASP MSTG sobre [Defensas anti-reversión en Android](https://github.com/OWASP/mastg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.md). #### Detectar intentos de hooking El hooking inyecta código en su **aplicación de billetera digital** en tiempo de ejecución. Los atacantes lo usan para interceptar datos sensibles (por ejemplo, claves criptográficas o PII), omitir controles de seguridad o cambiar la lógica de la aplicación. Consulte OWASP MASVS: [Defensas anti-reversión en Android](https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/) / *Verificación de integridad en tiempo de ejecución***.** #### Detectar la conexión de un depurador En dispositivos comprometidos, un atacante puede conectar un depurador a un `Release` compilación de su **aplicación de billetera digital**. Esto permite la inspección paso a paso del código Java/Kotlin y bibliotecas nativas, y puede exponer lógica y datos sensibles. Detecte la conexión de un depurador tanto en código Java/Kotlin como nativo, especialmente antes de ejecutar flujos sensibles. Para más información. Consulte OWASP MASVS: [Defensas anti-reversión en Android](https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/) / *Anti-Debugging*. #### Detectar emulador Los emuladores son un entorno de ejecución no confiable. Facilitan el análisis dinámico y la instrumentación para los atacantes. Detecte la ejecución en emulador lo antes posible. Hágalo al inicio de la aplicación y antes de inicializar el SDK de NFC Wallet. Consulte OWASP MASVS: [Defensas anti-reversión en Android](https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/) / *Detección de emuladores.* #### Detectar la manipulación de la aplicación Detecte la manipulación verificando el **aplicación de billetera digital** hash del certificado de firma en tiempo de ejecución. Esta verificación ayuda a detectar ataques de reempaquetado donde un atacante modifica el binario o los recursos y luego vuelve a firmar el APK. Los atacantes no pueden reproducir su certificado de firma. Ofusque el hash de certificado esperado para dificultar su localización y parcheo. Para obtener antecedentes, consulte [Implemente técnicas anti-manipulación](https://github.com/nowsecure/secure-mobile-development/blob/master/en/coding-practices/anti-tamper-techniques.md). Opcionalmente, envíe el hash del certificado de firma a su **backend**. Verifíquelo en el servidor antes de aceptar solicitudes desde la **aplicación de billetera digital**. #### Ofuscar la aplicación Ofusque su **aplicación de billetera digital** y sus componentes. Esto aumenta el costo de la ingeniería inversa. También hace más difícil localizar lógica y datos sensibles. Incluso si el SDK de NFC Wallet ya está ofuscado con DexGuard, debe ofuscar las API públicas del Thales NFC Wallet SDK: * Asegúrese de que se apliquen las reglas de ProGuard/R8 proporcionadas con los paquetes del SDK. Ver [Ofuscación del SDK de NFC Wallet](/nfc-wallet-sdk-android/es/security-and-privacy/nfc-wallet-sdk-obfuscation.md) * Preste especial atención a la regla de aplanamiento de paquetes: ```bash -flattenpackagehierarchy util ``` Use el nombre de paquete `util` para mantener la salida de ofuscación consistente con las reglas del SDK. Hay herramientas comerciales de ofuscación disponibles. En Android, recomendamos *DexGuard*. Consulte OWASP MASVS: [Defensas anti-reversión en Android](https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/) / *Ofuscación*. ### Codificación segura #### **Borre datos sensibles de la memoria** Almacene datos sensibles (por ejemplo, claves criptográficas e información de identificación personal (PII)) en matrices de bytes. En Java, no puede borrar de forma fiable objetos inmutables como `String` y `StringBuilder`. Tampoco puede controlar cuántas copias se crean en la memoria o cuánto tiempo permanecen accesibles. Borre explícitamente los datos sensibles. No confíe en el recolector de basura. Use un `finally` bloque para borrar búferes sensibles, incluso cuando no tenga un `catch` bloque. Esto reduce el riesgo de fugas si ocurre una excepción. {% code expandable="true" %} ```java byte[] password = this.getUserPassword(); try { // Use the password to login this.logUserIn(password); } finally { // Even if there is no exception catch here, there can be a //RuntimeException that should still trigger this finally block // to execute MemoryHelper.clearData(password); } //One way to implement a byte array wiping method is to rewrite every element in the arrays in the MemoryHelper class public static void clearData(byte[] baBuffer) { if (baBuffer == null) return; for(i = 0; i < baBuffer.length; i++) { baBuffer[i] = (byte)0; } } ``` {% endcode %} #### Siga estándares de codificación segura Siga estándares de codificación segura de fuentes confiables como Apple, Google y OWASP (Open Web Application Security Project). Si necesita orientación interna de Thales, contacte a la Comunidad de Seguridad de Handsets de Thales para solicitar acceso. Haga cumplir estos estándares con herramientas de análisis estático de código como PMD o Fortify. Agréguelas a su canal CI para prevenir regresiones. #### Ejecute verificaciones Android lint Ejecute Android Lint durante el desarrollo y antes de cada lanzamiento. Corrija los hallazgos temprano para reducir el riesgo de seguridad y calidad. Android Lint es una herramienta de análisis estático. Revisa su proyecto en busca de problemas de corrección, seguridad, rendimiento, usabilidad, accesibilidad e internacionalización. Ejecute lint localmente y en su canal CI: ```bash ./gradlew lint ``` Para más detalles, vea el sitio web de desarrolladores de Android: [Mejore su código con verificaciones lint](https://developer.android.com/studio/write/lint). ## Proteja los activos Esta sección describe las mejores prácticas en el desarrollo de aplicaciones para proteger activos. ### **Código de activación** Use en tokenización de tarjeta con un ciclo de vida de tiempo limitado: * Trátelo como un secreto de corta duración. No registre ni almacene ### token de registro FCM Si la aplicación de billetera digital gestiona FCM a nivel de aplicación: * Evite persistir el token de registro FCM por más tiempo del necesario. ### **Información de la tarjeta de financiación** Si la aplicación de billetera digital recopila datos de tarjetas de pago: * Deshabilite opciones de `EditField` , como autocompletar, copiar, pegar, etc. * Use un teclado seguro. * Valide las entradas antes de usarlas. * No almacene datos de tarjetas de pago de forma persistente. * Antes de mostrar la pantalla de entrada, aplique verificaciones en tiempo de ejecución (detección de root, hooking, depuración y manipulación). * Asegure la confidencialidad e integridad de este activo. Aplique los mismos controles a cualquier otra entrada sensible proveniente de fuera de la aplicación. ### Certificado de firma de la aplicación y certificado TLS * Controle el acceso al certificado de firma de la aplicación. * No lo divulgue a partes no confiables. * Asegure la confidencialidad e integridad de este activo. ### **Entradas de QR / DSRP (Importe)** Cuando la aplicación de billetera digital recopile el importe: * Deshabilite opciones de `EditField` , como autocompletar, copiar, pegar, etc. * Use un teclado seguro. Aplique los mismos controles a cualquier otra entrada sensible proveniente de fuera de la aplicación. ### Código QR (código de barras 2D) La aplicación debe implementarse para detectar y prevenir la captura del código QR en capturas de pantalla o que se visualice en pantallas no seguras. ### Otros activos sensibles * Ofusque el código y proteja las cadenas sensibles incluidas en el binario. * Reevalúe los activos en cada versión (nuevas funciones podrían añadir datos sensibles). * Evalúe el valor y la criticidad de cada activo y aplique la protección requerida. * No persista datos transitorios. Limpie los datos sensibles de la memoria cuando ya no sean necesarios. * Considere siempre que el dispositivo no es confiable. Use RASP para ayudar a proteger el binario de la aplicación y las bibliotecas de terceros en tiempo de ejecución. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.payments.thalescloud.io/nfc-wallet-sdk-android/es/security-and-privacy/security-guidance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.