Entrixy — cifrado de extremo a extremo

• Confidencialidad del contenido. El servidor no conoce ni la dirección de la barrera ni el número de teléfono, ni la dirección del webhook, ni las coordenadas, ni el BSSID del Wi-Fi ni el texto del saludo.
• Integridad verificable. Cualquier manipulación de un blob en el servidor rompe el descifrado (AES-GCM) y el cliente avisa de datos dañados.
• Compatibilidad futura de las claves. Un invitado accede solo a los objetos que se le han concedido. Comprometer una clave de invitado no revela nada sobre las demás.
• El límite del conocimiento cero. El servidor sí ve que existe una clave, las marcas de tiempo de actividad y los identificadores de objetos: los necesita para el enrutado. Ocultar los metadatos (esquemas cebolla) queda fuera del alcance.

Algorithm: AES-256-GCM. Disponible de serie en la JVM (mediante javax.crypto), y con soporte del Android Keystore. Da a la vez confidencialidad y autenticación.

Formato del texto cifrado

v1:<base64url(nonce || ciphertext || tag)>

• v1: — un prefijo de versión, para cambiar el formato más adelante.
• nonce — 12 bytes aleatorios, nuevos en cada cifrado.
• ciphertext+tag — todo lo que devuelve Cipher.doFinal; la etiqueta de 128 bits está incluida.
• base64url sin relleno: seguro tanto en una dirección como en JSON.

Fuente de entropía

K_master: la clave maestra del propietario

• 32 bytes aleatorios, generados en el primer arranque.
• Se guarda en EncryptedSharedPreferences con el nombre master_key y nunca sale del dispositivo en claro.
• Se usa solo para envolver K_obj para el almacenamiento local.

K_obj: la clave del objeto

• 32 bytes aleatorios, generados al crear cada objeto.
• Se guarda localmente como encrypt_k_master(K_obj) bajo la clave obj_key_{id}.
• Cifra el JSON de todos los campos sensibles del objeto (data_cipher en el servidor).
• Rotar significa un nuevo K_obj_new → volver a cifrar data_cipher y todos los paquetes que lo llevaban.

K_guest: la clave del paquete de invitado

• 32 bytes aleatorios, generados al crear una clave de invitado.
• Cifra el bundle — un JSON pequeño {obj_id: K_obj} con los objetos permitidos al invitado.
• Al servidor llega only bundle_cipher. El K_guest en sí el servidor no lo ve nunca.
• K_guest llega al invitado en el fragmento de la dirección: entrixy.com/key#<user_key><base64url(K_guest)> — un único bloque de 75 caracteres. El fragmento no viaja al servidor con la petición HTTP: es una garantía básica del navegador.

En el dispositivo del propietario (EncryptedSharedPreferences)

En el servidor

https://entrixy.com/key#<user_key(32)><K_guest_base64url(43)>

• El fragmento es un bloque de 75 caracteres: 32 caracteres de user_key y 43 caracteres de la clave de invitado.
• user_key — el identificador del lado del servidor. Sin él, el servidor no entrega el paquete.
• El fragmento (#...) nunca llega al registro del servidor — es una garantía del navegador.
• La página /key — JS corriente: lee location.hash, analiza el bloque y entrega la clave a la aplicación o a la versión web /app/. El servidor no ve nunca la clave.
• Si la aplicación no está instalada, la página copia el enlace al portapapeles y te envía a /download/android, desde donde la aplicación recoge la clave por sí misma.

Crear un objeto

1. El propietario pulsa Añadir: se genera K_obj.
2. Los campos se empaquetan en JSON y se cifran con K_obj → data_cipher.
3. POST /api/number_add con data_cipher más el tipo. El servidor devuelve un id.
4. Se guarda localmente: obj_key_{id} = encrypt_k_master(K_obj).

Actualizar un objeto

Construir el nuevo JSON localmente, cifrarlo con la K_obj → POST /api/number_update. K_obj existente, que no cambia.

Crear una clave de invitado

1. El propietario ha elegido [obj1, obj2, obj3]. Se genera K_guest.
2. Se ensambla el JSON del paquete: {obj_ids: [...], obj_keys: {1: K_obj1, ...}, welcome_cipher: ...}.
3. Se cifra con K_guest → bundle_cipher.
4. POST /api/key_create con bundle_cipher, obj_ids (en claro: para la matriz de acceso).
5. El servidor devuelve user_key.
6. Al propietario se le muestra un código QR con el enlace entrixy.com/key#{user_key}{base64url(K_guest)}.

El invitado acepta la clave

1. El invitado abre el código QR o el enlace. La página /key reads location.hash y entrega la clave a la aplicación o a la versión web.
2. El cliente pide POST /api/key_bundle.php con user_key → recibe bundle_cipher y la lista de obj_ids.
3. Descifra el paquete con K_guest→ obteniendo {obj_keys, welcome}.
4. K_guest y los descifrados obj_keys se guardan en EncryptedSharedPreferences del cliente invitado.
5. A partir de ahí, en cada llamada: GET del cifrado data_cipher del objeto → descifrado con la obj_key_{id}.

Revocar una clave de invitado

El propietario pulsa Eliminar → POST /api/key_revoke.php → el servidor borra el registro de la clave. En la siguiente petición del paquete el invitado recibe una negativa y pierde el acceso.

Rotar la clave de un objeto

El propietario pulsa Regenerar clave en los ajustes del objeto. Se genera K_obj_new, y se vuelven a cifrar todos los bundle_cipher que contienen ese objeto. El cliente no los conoce de memoria, así que el cliente del propietario reconstruye los paquetes: recoge el bundle_cipher de cada una de sus claves, lo descifra, inserta K_obj_newy vuelve a cifrar. Los nuevos blobs van al servidor en un solo lote.

Losing K_master significa perder el acceso a todos los objetos y claves; por eso la exportación es imprescindible.

• El propietario establece una passphrase (de al menos 8 caracteres).
• KDF: Argon2id (64 MB de memoria, 3 iteraciones, 1 hilo) → clave derivada de 32 bytes.
• La clave derivada cifra K_master → y produce master_backup_blob.
• El blob se muestra como Código QR y se guarda en Descargas. Se puede imprimir y guardar bajo llave en una caja fuerte.
• Restaurar en un dispositivo nuevo: escanear el código QR, introducir la frase de paso, se recupera K_master y el cliente descarga por adelantado todos los obj_keys del servidor —están en el paquete de las propias claves del propietario— y los vuelve a cifrar localmente.