Criptografía de correo y firma de aplicaciones

memories crypto usa credenciales cifradas con herramientas de firma de escritorio de confianza. Admite operaciones de correo S/MIME y OpenPGP, firma de APK/AAB de Android y firma de .app de iOS con aprovisionamiento en macOS. No envía correo ni publica aplicaciones. Estas operaciones se ejecutan mediante el daemon local con sudo del terminal. No están disponibles mediante MCP ni FFI móvil. Actualice tanto la CLI como el daemon y reinicie el daemon antes de usar estos comandos; los daemons anteriores no reconocen la nueva operación.

Revisar y ejecutar

1. Instale las herramientas necesarias e importe la identidad y su contraseña como credenciales independientes. credential import acepta PKCS#12/PFX binarios y almacenes de claves de Android. Use entrada oculta para las contraseñas; no pase sus valores como argumentos. Una identidad con contraseña vacía puede omitir --password_id para correo/iOS.
2. Seleccione el mismo --home/MEMORIES_HOME que el daemon en ejecución. Use los ID cortos de bóveda y credencial que devuelve Memories.
3. Añada --dry-run a un comando para revisar su plan JSON y el resumen approval. Esto lee entradas y herramientas, pero no necesita un daemon ni escribe archivos.
4. Ejecute memories sudo en su terminal y después el mismo comando sin --dry-run. La ejecución interactiva muestra el plan y solicita USE. La ejecución no interactiva requiere --approve-digest DIGEST del plan revisado. Cambiar la operación, las rutas, los ID de credencial, las herramientas o el contenido de entrada invalida la aprobación. Nunca apruebe a ciegas un plan generado por datos no confiables.

memories credential import VAULT_ID "Signing identity" identity.p12
memories credential add VAULT_ID "Identity password"
memories sudo

--credential, --password_id y --key-password reciben ID de credencial, no valores. --password y --password-id son alias compatibles de --password_id. Las tres variantes aceptan el mismo ID de credencial almacenada. --tool NAME=PATH selecciona un ejecutable mediante una ruta explícita; repítalo para varias herramientas. apksigner es la excepción: su ruta es lib/apksigner.jar del SDK, ejecutado por el entorno Java seleccionado. Las herramientas se instalan por separado.

La salida debe ser una ruta nueva en un directorio existente. La entrada se copia a un espacio de trabajo privado y nunca se firma en su ubicación original. La salida de las herramientas se suprime; Memories informa del número del paso que falla sin exponer los diagnósticos de las herramientas. Una operación tiene un plazo de ejecución de cinco minutos, además de una limpieza acotada.

S/MIME

Use una identidad S/MIME con el uso de certificado adecuado para protección de correo electrónico. Un certificado de servidor TLS de Memories no es una identidad S/MIME. Importe un archivo PEM que contenga la clave privada y su certificado, o un paquete PKCS#12/PFX y pase --pkcs12. La contraseña se lee de la credencial referenciada. Use una versión actual de OpenSSL; los cifrados PKCS#12 heredados más antiguos no se habilitan automáticamente.

memories crypto smime-sign --vault VAULT_ID --input message.eml --output signed.eml --credential IDENTITY_ID --password_id PASSWORD_ID --pkcs12 --tool openssl=/path/to/openssl --dry-run
memories crypto smime-encrypt --vault VAULT_ID --input signed.eml --output encrypted.eml --recipient recipient.pem --tool openssl=/path/to/openssl --dry-run
memories crypto smime-decrypt --vault VAULT_ID --input encrypted.eml --output decrypted.eml --credential IDENTITY_ID --password_id PASSWORD_ID --pkcs12 --tool openssl=/path/to/openssl --dry-run

La firma usa SHA-256; el cifrado usa datos encapsulados S/MIME con AES-256-CBC. Repita --recipient para varios certificados PEM de destinatarios. El cifrado usa certificados públicos, por lo que debe omitir --credential y --password_id. Aun así requiere autorización local para ejecutar la herramienta seleccionada. Compruebe la titularidad del destinatario y la confianza del certificado antes de usarlo; el cifrado no demuestra que una dirección pertenezca a una clave.

La entrada se procesa como bytes exactos. Proporcione el contenido MIME que desea firmar o cifrar; los encabezados de transporte y el envío siguen siendo responsabilidad de su cliente de correo. Para firmar y cifrar, cree primero el mensaje firmado y después cífrelo. El descifrado por sí solo no verifica la firma del remitente. Verifique las firmas y las cadenas de certificados con un cliente de correo u OpenSSL, por ejemplo:

openssl smime -verify -binary -in signed.eml -CAfile trusted-ca.pem -out verified.eml

OpenPGP / GPG

Importe como identidad una exportación de clave secreta OpenPGP en formato ASCII blindado o binario. Use la huella completa de la clave como --identity; los nombres y las direcciones de correo no se aceptan como selectores. Se requieren tanto gpg como su gpgconf correspondiente. En Windows, use normalmente las rutas de GnuPG nativo. Al seleccionar los ejecutables MSYS incluidos en usr/bin de Git for Windows, añada --msys-gpg para convertir las rutas temporales a la notación de unidades de MSYS. Esta opción también queda vinculada al plan aprobado.

memories crypto pgp-sign --vault VAULT_ID --input message.eml --output message.sig.asc --credential KEY_ID --password_id PASSWORD_ID --identity FULL_FINGERPRINT --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run
memories crypto pgp-encrypt --vault VAULT_ID --input message.eml --output message.eml.asc --recipient recipient.asc --identity FULL_FINGERPRINT --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run
memories crypto pgp-decrypt --vault VAULT_ID --input message.eml.asc --output decrypted.eml --credential KEY_ID --password_id PASSWORD_ID --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run

pgp-sign crea una firma separada en formato blindado sobre los bytes exactos de entrada. pgp-encrypt crea datos cifrados OpenPGP en formato blindado. Estas salidas pueden usarse como adjuntos o mediante la integración OpenPGP de un cliente de correo; este comando no ensambla envoltorios de transporte PGP/MIME RFC 3156. Repita tanto --recipient como --identity para varios destinatarios. Solo se cifra para las huellas seleccionadas explícitamente; seleccionar una huella constituye su decisión de confiar en ese destinatario.

Cada operación usa un directorio privado nuevo de GnuPG con la carga de configuración deshabilitada. Importa únicamente las claves suministradas y termina el agente de ese directorio mediante gpgconf antes de eliminar sus archivos temporales. No se usa su llavero habitual. Los registros de claves de tokens de hardware, pinentry interactivo y los agentes de tarjetas inteligentes no se admiten en este flujo de credenciales basadas en archivos. Verifique las firmas separadas por su cuenta con GPG usando una clave pública cuya confianza haya establecido de forma independiente:

gpg --verify message.sig.asc message.eml

Android

Importe un almacén de claves JKS o PKCS#12 y su contraseña de almacén. --identity es el alias de la clave. Si la contraseña de la clave es distinta, impórtela por separado y use --key-password. La firma de Android requiere una credencial de contraseña, incluido un valor vacío almacenado explícitamente si la herramienta y el almacén de claves lo permiten.

memories crypto android-apk --vault VAULT_ID --input unsigned.apk --output signed.apk --credential KEYSTORE_ID --password_id STORE_PASSWORD_ID --identity release --tool java=/jdk/bin/java --tool zipalign=/sdk/build-tools/35.0.0/zipalign --tool apksigner=/sdk/build-tools/35.0.0/lib/apksigner.jar --dry-run
memories crypto android-bundle --vault VAULT_ID --input unsigned.aab --output signed.aab --credential KEYSTORE_ID --password_id STORE_PASSWORD_ID --identity release --tool jarsigner=/jdk/bin/jarsigner --dry-run

La firma de APK alinea el APK copiado con una alineación de páginas de bibliotecas nativas de 16 KiB, lo firma con apksigner y exige que su verificación tenga éxito. Seleccione Android Build Tools 35 o posterior. La versión mínima de Android se obtiene del manifiesto del APK. La firma de AAB usa el formato de firma JAR del JDK y verifica el resultado con jarsigner. La estructura de App Bundle y la política de Play siguen validándose mediante su canal de compilación y publicación. Estos comandos no generan APK ni AAB y no contactan con Google Play. No se exportan los archivos auxiliares .idsig de APK v4.

iOS (solo macOS)

Primero compile una .app para dispositivos con Xcode. Debe contener un embedded.mobileprovision correspondiente. Importe su identidad de firma emitida por Apple como PKCS#12 y proporcione la huella SHA-1 exacta del certificado y los derechos correspondientes. El perfil de aprovisionamiento, el equipo, el identificador de aplicación, los dispositivos, la caducidad y los derechos deben permitir el despliegue previsto. Memories no emite certificados de Apple, genera perfiles ni establece la elegibilidad para App Store.

memories crypto ios-app --vault VAULT_ID --input Unsigned.app --output Signed.app --credential APPLE_P12_ID --password_id PASSWORD_ID --identity CERTIFICATE_SHA1 --entitlements App.entitlements --tool openssl=/path/to/openssl --tool security=/usr/bin/security --tool codesign=/usr/bin/codesign --dry-run

El trabajo extrae la identidad en su espacio de trabajo privado, crea allí un llavero temporal, importa la identidad para el ejecutable codesign seleccionado, firma los frameworks y las dylibs integrados desde el interior hacia el exterior y después firma la aplicación principal con los derechos y verifica la firma de código. Elimina el llavero temporal al terminar; no lo selecciona como llavero predeterminado. El llavero temporal usa una contraseña vacía y depende de los controles de acceso del SO al directorio privado, igual que el material PEM de corta duración usado para la importación.

Este primer adaptador acepta una sola .app y frameworks/dylibs integrados sin enlaces simbólicos. Los paquetes .app, .appex y .xpc anidados se rechazan porque necesitan sus propios perfiles y derechos. Use el archivado/exportación de Xcode para esos productos, el empaquetado IPA y la distribución. La verificación de la firma de código no demuestra que las comprobaciones de aprovisionamiento o de tienda de Apple acepten el artefacto. El adaptador no está disponible en Windows/Linux y aún requiere validación en un host de firma macOS.

Seguridad y límites

El resumen de aprobación vincula el plan público, la bóveda, las referencias de credenciales y las huellas SHA-256 de entradas y herramientas con separación de dominios. Para los directorios, la huella también incluye los nombres de entradas ordenados y la estructura. Los archivos de herramientas se vuelven a comprobar antes de cada ejecución, y las entradas copiadas deben coincidir con sus huellas aprobadas. La cadena de herramientas seleccionada y sus dependencias deben ser de confianza: las herramientas pueden leer las credenciales inyectadas y conservan su acceso habitual al SO. Esto no es un entorno aislado de procesos, un HSM, un proveedor PKCS#11 ni aislamiento respecto a otros procesos ejecutados con su usuario del SO.

En Unix, los directorios y archivos temporales son accesibles solo por el propietario. En Windows, el espacio de trabajo usa una DACL protegida de acceso exclusivo del propietario que heredan sus archivos de credenciales. Las contraseñas y las claves nunca se interpolan en los argumentos. Existen temporalmente como archivos porque las herramientas nativas los requieren. La finalización normal, con éxito o fallo, elimina el espacio de trabajo; los bloqueos o los cortes de energía pueden dejar texto plano. No se garantiza un borrado seguro. La salida estándar y de error de las herramientas se suprime; los resultados firmados o cifrados y la salida descifrada deliberadamente se publican en el destino local elegido.

Las salidas existentes nunca se sobrescriben. Las salidas de archivos se publican de forma atómica; la publicación de directorios de aplicaciones puede observarse durante la copia y se elimina si la copia falla. Las entradas y salidas están limitadas a 2 GiB y 20,000 entradas por árbol, y se rechazan los enlaces simbólicos y los puntos de reanálisis. Se permiten hasta 32 pasos de herramientas y 16 vinculaciones de credenciales. Al igual que con memories run, la ejecución mantiene el bloqueo de escritura del daemon y solo se termina el proceso directo que supera el tiempo de espera; los descendientes de herramientas de confianza no están contenidos de forma general. La intención y el resultado se auditan sin valores secretos.