Utilice App Attest y DeviceCheck para prevenir fraudes en iOS

App Attest y DeviceCheck son importantes para retener ingresos.

Como desarrollador de aplicaciones, existen algunas formas de ganar dinero con sus creaciones. Sin embargo, es posible que no todos estén dispuestos a pagar, pero sí quieran acceder a algunas funciones premium pagas.

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

Al utilizar el marco DeviceCheck de Apple, puede garantizar que solo los usuarios autorizados puedan acceder a contenido y promociones premium.

Apple proporciona el marco DeviceCheck para ayudar a su aplicación a reducir los intentos de uso fraudulento de las funciones premium de las aplicaciones.

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 varios elementos gratis. Podrían hacerlo desinstalando y volviendo a instalar la aplicación.

El marco DeviceCheck permite que su aplicación vea si un dispositivo de hardware en particular ya recibió una oferta promocional.

Estas comprobaciones están vinculadas al Secure Enclave de cada dispositivo Apple y se combinan con una cuenta Apple y una clave criptográfica privada para garantizar la autorización.

1. Dos bits de estado del dispositivo almacenados por Apple junto con una marca de tiempo
2. Por dispositivo, por desarrollador
3. Persistente en los reinicios de dispositivos de hardware

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

DeviceCheck realiza un seguimiento de los dispositivos por dispositivo y por desarrollador de aplicaciones.

El estado de DeviceCheck se guarda después de reiniciar el dispositivo, en caso de que el dispositivo Apple se restablezca por completo a la condición de fábrica.

Su aplicación puede utilizar estas comprobaciones para ver si una determinada promoción fue utilizada anteriormente por alguna aplicación, por alguna cuenta Apple, en algún dispositivo Apple.

App Attest también es parte de DeviceCheck.framework y le permite rastrear cualquier servicio que su aplicación presente para determinar si ese servicio es uno que su aplicación reconoce.

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

Si el servidor de Apple responde que la aplicación y el servicio son válidos, su servidor informa al dispositivo de envío que la solicitud es válida.

Dado que cada solicitud está vinculada a información específica del hardware del dispositivo, las solicitudes no se pueden falsificar ni copiar para otros dispositivos.

App Attest también evita que se copien copias ilegítimas de funciones de aplicaciones o servicios premium de un dispositivo a otro.

App Attest proporciona tres piezas clave de información que tu aplicación puede usar para verificar que una solicitud provino de un dispositivo Apple auténtico y autorizado:

1. Dispositivo Apple original
2. Identidad de aplicación auténtica
3. Carga útil confiable

Al comprobar si un dispositivo Apple es genuino, podrá verificar que la aplicación y el contenido premium realmente se estén ejecutando en un dispositivo Apple real.

La identidad auténtica de la aplicación garantiza que la aplicación que realiza la solicitud es tuya y que es una copia legítima, que se ha descargado de la App Store.

Se pueden verificar cargas útiles confiables para confirmar que la función premium o el contenido promocional estén autorizados, se hayan comprado y no se hayan alterado.

Al utilizar estos tres datos, su aplicación puede asegurarse de que el contenido esté disponible para el usuario. Esto evita que los piratas informáticos y los que rompen la seguridad intenten descargar o reutilizar contenido premium pagado y autorizado en otro dispositivo Apple.

La verificación de la autenticidad del dispositivo se realiza mediante el examen de un par de claves seguras en el dispositivo, que utiliza Secure Enclave. Se combina con una solicitud de App Attest del dispositivo que se genera utilizando el par de claves válido.

Los pares de 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 provenir.

La PKI es extremadamente segura e incluso las supercomputadoras más eficientes del mundo necesitan años para descifrarla.

Cuando tu aplicación realiza 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 sincroniza ni se copia entre dispositivos.

Una copia codificada de cada aplicación solicitante Identificación del paquete También se envía con cada solicitud de verificación.

Generando una certificación de clave.

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

Para poder usar App Attest en tu aplicación, esta debe estar ejecutándose en un dispositivo con un enclave seguro. Por lo tanto, siempre debes comprobar la posibilidad de usar App Attest en tu aplicación antes de hacerlo.

También hay tres partes para agregar App Attest a tu aplicación:

1. Generar una clave AppAttest
2. Verificando claves
3. Generar y verificar afirmaciones

Para crear una clave AppAttest en el código de su aplicación, utilice el .shared propiedad en el DCAppAttestService objeto de clase como este:

let appAttestService = DCAppAttestService.shared

Esto crea una variable local llamada appAttestService desde el .shared propiedad y almacena una copia del objeto de servicio compartido.

Una vez que tenga una instancia de la .shared propiedad, 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 DCAppAttestService clase. Luego compruebas su .isSupported propiedad para asegurarse de que AppAttest esté disponible en este dispositivo y luego generar una clave con la .generatekey método.

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

Una vez que tengas la clave, puedes guardarla para usarla más adelante, probablemente en un objeto que hayas definido y creado previamente.

DeviceCheck.framework también admite interfaces Objective-C si todavía utiliza ese lenguaje en lugar de Swift.

Si el .isSupported devoluciones de propiedad NO o la tecla vuelve nil No puedes usar AppAttest en tu aplicación.

Tenga en cuenta que hay algunos casos en los que el código aún puede regresar NO Para el .isSupported. Incluso si el dispositivo tiene un enclave seguro (generalmente si el código se llama desde una extensión de la aplicación).

Su aplicación también debe estar preparada para manejar estos casos. En estas situaciones, suponga que el autor de la llamada no es confiable y luego diseñe su 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 segunda mejor calidad cuando el .isSupported devoluciones de propiedad NO.

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

Para ello, su aplicación deberá crear un desafío de servidor único. Este desafío está diseñado para certificar la clave que generó con un desafío de su 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 para cada ocurrencia de certificación de clave.

La certificación de clave proporciona un nivel adicional de seguridad al evitar ataques de tipo «man-in-the-middle» y de repetición.

El primer paso de este proceso es generar una certificación de clave. Se utiliza el mismo objeto de servidor de certificación de aplicación que el anterior, pero con la .attestKey método.

Usando este método, pasas el original keyIDun hash de datos del cliente, un attestationObjecty una variable de error opcional que .attestKey El método toma como entrada.

A su regreso, el attestationObject Se puede utilizar para el desafío del servidor.

El propósito de .attestKey El método consiste en utilizar la clave privada del dispositivo para crear una solicitud de certificación de hardware opaca, vinculada a la clave y a este dispositivo específico.

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

Sólo el servidor de Apple sabe cómo verificar el dispositivo a nivel de hardware basándose en la información que se le envía, lo que hace 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 recibe la respuesta de Apple y se asegura de que es válida, debe enviar la respuesta junto con cualquier carga útil personalizada a su 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 cualquiera piratear sus funciones premium y habilitar contenido no autorizado.

Hay cuatro secciones adicionales en la documentación del marco DeviceCheck que querrás consultar:

1. Acceder y modificar datos por dispositivo
2. Evaluación del riesgo de fraude
3. Establecer la integridad de su aplicación
4. Validación de aplicaciones que se conectan a su servidor

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

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

Consulte la documentación para el DCDevice y DCError clases en el marco DeviceCheck.

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

Usando un Swift/C estándar case declaración, luego puede asignar un resultado de código de error a una cadena que su aplicación pueda mostrar al usuario.

Actualmente, hay cinco predefinidos DCError códigos establecidos por Apple:

1. característica no compatible
2. entrada inválida
3. tecla inválida
4. servidor no disponible
5. Error desconocido del sistema

featureUnsupported significa que parte o la totalidad de la API de DeviceCheck no está disponible. invalidKey significa que la clave que intentaste utilizar falló.

Ante cualquier error que devuelva una API de Apple o la certificación de clave, su aplicación debe mostrar una cadena de texto localizada adecuada al usuario, informándole por qué no funcionó.

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

Piense en los dominios de error como Categorías Los errores se organizan en. Al utilizar el DCErrorDomain cadena, puede brindar a los usuarios información útil adicional sobre qué tipo de error ocurrió.

DeviceCheck y AppAttest son adiciones bienvenidas al desarrollo de aplicaciones de Apple. Al usarlos en su aplicación, puede asegurar sus funciones premium y sus ingresos sin demasiado trabajo adicional.