Modelo de seguridad y recuperación

BloqueApp separa la identidad del servicio, la identidad de la persona aprobadora, la política firmada, las autorizaciones firmadas y la aplicación local de reglas Android. Estos controles reducen accesos accidentales o no autorizados; no convierten un teléfono de consumo en un dispositivo inviolable. La arquitectura describe la división de autoridad; los conceptos compartidos cubren las autorizaciones, las solicitudes y el funcionamiento sin conexión. Consulte también el glosario y las limitaciones.

Resumen de la configuración como Device Owner

Device Owner es el rol de administración de Android que permite la aplicación de reglas por paquete de BloqueApp. Configurarlo es un proceso de inscripción separado que se realiza en el teléfono; emparejarlo con una persona aprobadora no concede este rol. El siguiente flujo es un resumen, no un procedimiento listo para instalar. La prueba actual del proyecto cubre la inscripción QR en un Galaxy A32 de repuesto. La entrega de un Galaxy A36 no se ha verificado.

flowchart TD
    A[La persona propietaria acepta la configuración] --> B[Respaldar los datos deseados y confirmar la recuperación de la cuenta]
    B --> C{¿El dispositivo cumple los requisitos de inscripción?}
    C -->|No| X[Detenerse y resolver los requisitos]
    C -->|Sí| D[La persona propietaria realiza un restablecimiento autorizado]
    D --> E[En la pantalla apta de configuración, escanear el QR]
    E --> F[El QR apunta a un APK por HTTPS e incluye su checksum]
    F --> G[El asistente de Android descarga y aprovisiona el DPC]
    G --> H[Verificar que BloqueApp sea realmente Device Owner]
    H --> I[Emparejar, sincronizar política firmada y revisar permisos]
    I --> J[Comprobar un objetivo de prueba inocuo]

La persona propietaria debe poder desbloquear el dispositivo y recuperar cualquier cuenta que Android solicite después del restablecimiento. El restablecimiento borra los datos del dispositivo. La inscripción QR se completa en el asistente de Android con el consentimiento de la persona propietaria; ver BloqueApp instalado no demuestra que la inscripción como Device Owner haya funcionado. Continúe solo después de verificar la titularidad; luego empareje y compruebe un objetivo inocuo antes de confiar en la aplicación de reglas. Consulte la arquitectura para conocer los límites de este rol.

Emparejar con una persona aprobadora

El emparejamiento vincula una identidad del dispositivo Android con una identidad autenticada de la persona aprobadora. Es independiente de la inscripción como Device Owner: por sí solo no habilita la aplicación de reglas Android. El intercambio comienza con un código de un solo uso y duración limitada; el número de seis dígitos sirve para comparar las pantallas y el teléfono debe confirmar que coinciden.

flowchart TD
    A[El teléfono muestra un código de emparejamiento temporal] --> B[La persona aprobadora inicia sesión en el navegador y envía ese código]
    B --> C[El servidor crea un emparejamiento pendiente y muestra un número de seis dígitos]
    C --> D[Comparar el número en el navegador y el teléfono]
    D --> E{¿Coinciden los números?}
    E -->|No| F[No confirmar; reiniciar el emparejamiento si hace falta]
    E -->|Sí| G[Confirmar en el teléfono]
    G --> H[El servidor registra el emparejamiento]
    H --> I[El teléfono puede sincronizar y verificar la política firmada]
    H --> J[La persona aprobadora puede habilitar Web Push por separado]

Comparar los números ayuda a detectar si se ingresó un código de otro dispositivo; por sí solo no autoriza el emparejamiento. Solo el teléfono autenticado puede confirmar el intercambio pendiente. La sincronización de política es un paso autenticado aparte, y Web Push para el navegador es opcional. Consulte los límites de autoridad para ver cómo se reparten las responsabilidades entre el servicio, el navegador y el teléfono.

Identidades separadas

El teléfono restringido se autentica ante el servicio con un bearer token de dispositivo. El navegador usa un token de sesión aleatorio distinto en una cookie Secure, HttpOnly y SameSite=Strict. SQLite guarda hashes de estos tokens bearer y de sesión, no los valores que se entregan al crearlos. El emparejamiento vincula un dispositivo con una persona aprobadora; los identificadores enviados por el dispositivo no cuentan por sí solos como autorización.

El dispositivo y el navegador usan rutas autenticadas diferentes. Las mutaciones del navegador también requieren una solicitud JSON del mismo origen, y la página web no recibe credenciales del dispositivo. El teléfono no recibe las credenciales de la persona aprobadora. La política se publica desde la fuente controlada por el operador, no desde ninguno de los dos clientes.

Decisiones durables e idempotencia

Una decisión se verifica frente a la persona aprobadora autenticada, el dispositivo emparejado, la solicitud pendiente y vigente, la política actual, el paquete solicitado y la duración. El servicio escribe la decisión y cualquier autorización resultante en una transacción SQLite. Las decisiones concurrentes se serializan para que solo una pueda ganar para una solicitud. Si se reintenta con la misma clave de idempotencia y el mismo cuerpo, el servicio devuelve el resultado guardado; usar esa clave con otro cuerpo produce un conflicto.

Después del commit, el servicio intenta enviar un aviso SignalR de mejor esfuerzo. Si no puede enviarlo, la decisión no se revierte. El teléfono obtiene el comprobante persistido por HTTPS autenticado, y una notificación solo dirige a ese comprobante. La PWA confirma el éxito después de recibir la respuesta del endpoint de decisión.

Política y autorizaciones firmadas

El servicio firma las instantáneas de política y las autorizaciones con su clave RSA configurada. La compilación Android incluye la clave pública, el emisor y el identificador de clave fijados como datos de confianza. Antes de exponer los datos, el cliente verifica la firma y luego comprueba el endpoint y el contexto esperados: audiencia y dispositivo, asociación, solicitud, paquete, identificador y revisión de política, alcance, fecha de emisión y vencimiento. Rechaza envolturas malformadas o demasiado largas, contextos incompatibles y autorizaciones fuera de la ventana permitida.

El teléfono guarda una marca de autorización consumida antes de programar o aplicar acceso. La expiración, la revocación y la recuperación tras un reinicio conservan el historial contra reproducción; un comprobante histórico no permite volver a aplicar una autorización antigua. La política efectiva firmada actual sigue decidiendo si el paquete está seleccionado, si aplica el descanso y si el alcance está habilitado. Una autorización ya aceptada conserva su vencimiento original cuando cambia la política, pero las restricciones nuevas siguen aplicándose. La excepción al descanso es un alcance firmado explícito y solo se acepta si la política actual la permite.

La caché de política rechaza volver a una revisión anterior y documentos distintos con la misma revisión. Una instantánea corrupta o ausente no convierte en ilimitado un paquete que antes estaba administrado. El estado de aplicación protegido por dispositivo se separa de los secretos de emparejamiento protegidos por credenciales. El almacenamiento y los controles del sistema no protegen contra quien controla o restablece el teléfono.

Notificaciones y mensajes en tiempo real

Web Push despierta el service worker del navegador y puede mostrar el estado de una solicitud aunque la página de aprobación esté cerrada. La cola durable reintenta la entrega dentro de límites, pero los proveedores push y la conectividad pueden retrasarla o perderla. El contenido de una notificación no es una decisión de aprobación. Las acciones de notificación siguen usando el endpoint autenticado del mismo origen, y la respuesta guardada en el servidor es la autoridad.

El hub SignalR Android acepta un bearer de dispositivo emparejado en el encabezado Authorization y rechaza tokens en la cadena de consulta y cookies de aprobación. Limita la conexión al dispositivo autenticado y no ofrece un método de suscripción a grupos para clientes. El mensaje RequestChanged contiene un identificador y una versión para actualizar; no concede autorización. El cliente en primer plano obtiene un comprobante durable. La reanudación y los reintentos transitorios acotados ofrecen vías de recuperación separadas.

Privacidad y recuperación

El procesamiento de eventos de uso permanece en el teléfono. Este flujo no sube capturas de pantalla, texto de accesibilidad, mensajes, URL completas del navegador ni ubicación precisa. El servicio conserva las solicitudes y decisiones necesarias para los comprobantes y el emparejamiento, además de los datos de suscripción push cuando la persona aprobadora los habilita. La entrega Web Push depende de configuración.

Si se deniega el acceso, no se puede verificar una firma o política, falta Usage Access o la contabilidad se vuelve ambigua, la ruta local falla de forma cerrada para el paquete seleccionado o la sesión bancaria afectada. Las aplicaciones esenciales y las rutas explícitas de recuperación siguen disponibles. La activación del antiguo administrador del dispositivo (Device Admin) no concede autoridad de propietario del dispositivo (Device Owner); la suspensión de paquetes requiere que la aplicación esté realmente aprovisionada como Device Owner. Un restablecimiento puede eliminar ese aprovisionamiento, por lo que no se promete resistencia al restablecimiento. Para las opciones y los pasos prácticos de recuperación, consulte la guía de uso y las limitaciones.