Utiliza App Attest y DeviceCheck para prevenir el fraude en iOS

App Attest y DeviceCheck son importantes para retener ingresos.

Los desarrolladores de aplicaciones pueden minimizar el fraude utilizando App Attest y DeviceCheck, dos herramientas proporcionadas por Apple. Aquí te explicamos cómo usarlas para prevenir modificaciones no autorizadas en tu aplicación y evitar que los usuarios adquieran ilegítimamente contenido premium.

Como desarrollador de aplicaciones, hay varias formas de ganar dinero con tus creaciones. Sin embargo, no todos pueden estar dispuestos a pagar, pero aún así quieren acceder a algunas funciones premium de pago.

Los desarrolladores buscan evitar este tipo de comportamiento. Aquí es donde entran en juego App Attest y DeviceCheck de Apple.

Al usar el marco de trabajo DeviceCheck de Apple, puedes asegurarte de que solo los usuarios autorizados puedan acceder a contenido premium y promociones.

DeviceCheck

Apple proporciona el marco de trabajo DeviceCheck para ayudar a tu aplicación a reducir el uso fraudulento de funciones premium de la aplicación.

DeviceCheck ayuda a mitigar el fraude en ofertas promocionales en aplicaciones.

Por ejemplo, si tu aplicación ofrece promociones o contenido premium, algunos usuarios pueden intentar abusar de las funciones para obtener múltiples artículos gratuitos. Podrían hacer esto desinstalando y volviendo a instalar tu aplicación.

El marco de trabajo DeviceCheck permite a tu aplicación verificar si un dispositivo hardware en particular ya ha recibido una oferta promocional.

Estas verificaciones están vinculadas al Secure Enclave en cada dispositivo Apple. Se combinan con una Cuenta de Apple y una clave criptográfica privada para garantizar la autorización.

Dos bits de estado de dispositivo almacenados por Apple junto con una marca de tiempo
Por dispositivo, por desarrollador
Persistente en reinicios de dispositivo hardware

Los dos bits almacenados por Apple vinculan a cada desarrollador de Apple a un estado conocido para cualquier promoción previamente registrada por aplicación. Junto con la marca de tiempo, puedes usar los bits de cualquier manera que desees para que tu aplicación determine el estado de la promoción.

DeviceCheck realiza un seguimiento de los dispositivos en una base por dispositivo, por desarrollador de aplicaciones.

El estado de DeviceCheck se guarda a través de reinicios de dispositivos, si el dispositivo Apple se restablece completamente a la condición de fábrica.

Estas verificaciones pueden ser utilizadas por tu aplicación para comprobar si una determinada promoción fue utilizada previamente por cualquier aplicación en cualquier Cuenta de Apple en cualquier dispositivo Apple.

App Attest

App Attest también es parte de DeviceCheck.framework y te permite realizar un seguimiento de cualquier servicio específico que ofrezca tu aplicación para determinar si ese servicio es uno que tu aplicación reconoce.

Para usar App Attest necesitarás un servidor o un servicio basado en la nube para recibir tokens basados en hardware desde el dispositivo del usuario, junto con una solicitud de App Attest. Tu servidor debe luego reenviar estas solicitudes de aplicaciones a un servidor de App Attest de Apple para su verificación.

Si el servidor de Apple devuelve que la aplicación y el servicio son válidos, tu servidor informa al dispositivo remitente que la solicitud es válida.

LEAR  Nuestras predicciones para el evento 'It's Glowtime'! [The CultCast]

Dado que cada solicitud está vinculada a información específica del hardware del dispositivo, las solicitudes no pueden ser falsificadas o copiadas para otros dispositivos.

App Attest también evita que copias ilegítimas de funciones premium de la aplicación o servicios sean copiadas de un dispositivo a otro.

Tres piezas fáciles

App Attest proporciona tres piezas clave de información que tu aplicación puede utilizar para verificar que una solicitud proviene de un dispositivo Apple auténtico y autorizado:
Dispositivo Apple genuino
Identidad de aplicación auténtica
Carga útil confiable

Verificar un dispositivo Apple genuino te permite confirmar que la aplicación y el contenido premium se están ejecutando en un dispositivo Apple real.

La identidad de la aplicación auténtica se asegura de que la aplicación que realiza la solicitud sea tu aplicación y que sea una copia legítima. Una que haya sido descargada desde la App Store.

Las cargas útiles confiables se pueden verificar para confirmar que la función premium o el contenido promocional están autorizados, se han comprado y no se han manipulado.

Al utilizar estas tres piezas de información, tu aplicación puede asegurarse de que el contenido esté disponible para el usuario. Esto evita que los piratas informáticos y los jailbreakers intenten descargar o reutilizar contenido premium pagado y autorizado en otro dispositivo Apple.

La verificación de dispositivos genuinos se logra mediante un examen de un par de claves seguras en el dispositivo, que es utilizado por el Secure Enclave. Se combina con una solicitud de App Attest del dispositivo que se genera utilizando el par de claves válido.

Las claves seguras son parte de lo que se llama Infraestructura de Clave Pública (PKI) que utiliza cifrado para crear claves seguras y las envía a través de una red.

Al utilizar claves seguras y firmas digitales, una aplicación y un dispositivo pueden confirmar que una solicitud proviene de quien dice ser.

PKI es extremadamente seguro y hasta los supercomputadoras más potentes del mundo requieren años para descifrarlo.

Cuando tu aplicación hace una solicitud de App Attest, puede usar las claves seguras para hacerlo, que luego pueden ser verificadas por el servidor. Cada clave segura es única por instalación y no se sincronizan ni copian en otros dispositivos.

Una copia codificada del ID de paquete de cada aplicación solicitante también se envía con cada solicitud para su verificación.

Generando un atestación de clave.

Agregando App Attest a tu aplicación

Para agregar App Attest a tu aplicación en Xcode, primero debes incluir el marco de trabajo DeviceCheck en la pestaña de Información de compilación en el panel de marcos de trabajo de cada objetivo del proyecto.

Para usar App Attest en tu aplicación, la aplicación debe estar en ejecución en un dispositivo con un Secure Enclave. Por lo tanto, siempre debes verificar la capacidad de usar App Attest en tu aplicación antes de hacerlo realmente.

También hay tres partes para agregar App Attest a tu aplicación:
Generar una clave de AppAttest
Verificar claves
Generar y verificar afirmaciones

LEAR  Trump le dice a sus seguidores que su multa de $355 millones por fraude es interferencia en las elecciones, por Reuters. Trump le dice a sus seguidores que su multa de $355 millones por fraude es interferencia en las elecciones, por Reuters.

Para crear una clave de AppAttest en el código de tu aplicación, utiliza la propiedad .shared en el objeto de clase DCAppAttestService de esta manera:

let appAttestService = DCAppAttestService.shared

Esto crea una variable local llamada appAttestService a partir de la propiedad .shared y almacena una copia del objeto de servicio compartido.

Una vez que tienes una instancia de la propiedad .shared, puedes usarla para crear una clave:

Generando una clave de dispositivo para App Attest.

En el código anterior, primero obtienes una instancia compartida de la clase DCAppAttestService. Luego verificas su propiedad .isSupported para asegurarte de que AppAttest está disponible en este dispositivo, y luego generas una clave con el método .generatekey.

Si .generatekey devuelve un error, lo verificas y lo manejas, de lo contrario la clave se devuelve en keyId.

Una vez que tienes la clave, puedes guardarla para usarla más adelante, probablemente en un objeto que definiste y creaste anteriormente.

El marco de trabajo DeviceCheck también admite interfaces Objective-C si todavía estás utilizando ese lenguaje en lugar de Swift.

Si la propiedad .isSupported devuelve NO o la clave devuelve nil no puedes usar AppAttest en tu aplicación.

Ten en cuenta que hay algunos casos en los que el código aún puede devolver NO para el .isSupported. Incluso si el dispositivo tiene un Secure Enclave (por lo general si el código se llama desde una extensión de la aplicación).

Tu aplicación debe estar preparada para manejar estos casos también. En estas situaciones, asume que el llamante no es de confianza, luego diseña tu propia lógica de código en función de un conjunto de reglas de evaluación de riesgos para determinar si se deben permitir las funciones premium.

Este enfoque es una validación de segundo nivel cuando la propiedad .isSupported devuelve NO.

Validar clave

Suponiendo que tienes una clave válida del código anterior, el siguiente paso es validar o atestar la clave.

Para ello, tu aplicación deberá crear un desafío de servidor único. Este desafío está diseñado para atestiguar la clave que generaste con un desafío de tu servidor, que valida la clave en combinación con la información de la cuenta del usuario.

También necesitarás diseñar un código del lado del servidor para hacer esto en cada ocurrencia de atestación de clave.

La atestación de la clave proporciona un nivel adicional de seguridad al prevenir ataques de intermediarios y de repetición.

El primer paso en este proceso es generar una atestación de clave. Utilizas el mismo objeto de servidor de atestación de aplicaciones que mencionamos anteriormente, pero con el método .attestKey.

Usando este método, pasas el ID de clave original, un hash de datos del cliente, un objeto de atestación y una variable de error opcional que el método .attestKey toma como entrada.

Al regresar, el objeto de atestación se puede utilizar para el desafío de servidor.

El propósito del método .attestKey es utilizar la clave privada del dispositivo para crear una solicitud de atestación de hardware opaco. Uno vinculado a la clave y a este dispositivo específico.

LEAR  Por qué los miles de millones en efectivo de Warren Buffett en Berkshire Hathaway es una señal bajista para el mercado de valores

Esta atestación de hardware luego se envía a un servidor de atestación de Apple para su verificación de hardware. Una vez verificada, el servidor de Apple devolverá un objeto de atestación anónimo a tu aplicación.

Solo el servidor de Apple sabe cómo verificar el dispositivo a nivel de hardware según la información enviada, lo que hace que sea muy difícil para los piratas informáticos interceptar la solicitud y devolver un falso positivo que habilite las funciones premium.

Una vez que la aplicación reciba la respuesta de Apple y se asegure de que es válida, la aplicación debe enviar la respuesta junto con cualquier carga útil personalizada a tu servidor para su verificación final.

Este proceso bastante complejo, combinado con la verificación de hardware de Apple y una clave privada, hace que sea muy difícil para cualquier persona hackear tus funciones premium y habilitar contenido no autorizado.

Hay cuatro secciones adicionales en la documentación del marco de trabajo DeviceCheck que querrás consultar:
Acceder y modificar datos por dispositivo
Evaluar el riesgo de fraude
Establecer la integridad de tu aplicación
Validar aplicaciones que se conectan a tu servidor

Manejo de errores

En el código anterior, vimos que algunas API de DeviceCheck de Apple devuelven un código de error opcional.

Tu aplicación debe manejar estos códigos e informar al usuario si ocurre algún error.

Consulta la documentación de las clases DCDevice y DCError en el marco de trabajo DeviceCheck.

También puedes obtener códigos de error visualizables por el usuario de cualquier API del marco de trabajo de DeviceCheck que devuelva un DCError obteniendo el valor de su propiedad .Code. Esto se define como un enum (un número) que se puede asignar a un conjunto de códigos de error predefinidos de Apple.

Usando un caso estándar de Swift/C, puedes mapear un código de error a una cadena visualizable por el usuario que tu aplicación muestre al usuario.

Actualmente, Apple ha establecido cinco códigos de error predefinidos de DCError:
featureUnsupported
invalidInput
invalidKey
serverUnavailable
unknownSystemFailure

featureUnsupported significa que alguna o toda la API de DeviceCheck no está disponible. invalidKey significa que la clave que intentaste usar falló.

Ante cualquier retorno de error de una API de Apple o de la atestación de la clave, tu aplicación debe mostrar una cadena de texto localizada apropiada al usuario informándole por qué no funcionó.

También puedes verificar la variable global DCErrorDomain después de los errores para determinar el dominio del último error ocurrido.

Piensa en los dominios de error como categorías en las que se organizan los errores. Al usar la cadena DCErrorDomain, puedes brindar a los usuarios información adicional útil sobre qué tipo de error ocurrió.

DeviceCheck y AppAttest son adiciones bienvenidas al desarrollo de aplicaciones de Apple. Al utilizarlas en tu aplicación, puedes asegurar tus funciones premium e ingresos sin mucho trabajo adicional.