Cryptographie du courrier et signature d'applications

memories crypto utilise des identifiants chiffrés avec des outils de signature de bureau fiables. Il prend en charge les opérations de courrier S/MIME et OpenPGP, la signature Android APK/AAB et la signature de .app iOS provisionnées sur macOS. Il n'envoie pas de courrier et ne publie pas d'applications. Ces opérations s'exécutent via le démon local avec sudo dans le terminal. Elles ne sont disponibles ni via MCP ni via la FFI mobile. Mettez à jour la CLI et le démon, puis redémarrez le démon avant d'utiliser ces commandes ; les anciens démons ne reconnaissent pas la nouvelle opération.

Examiner et exécuter

1. Installez les outils requis et importez l'identité et son mot de passe comme identifiants distincts. credential import accepte les PKCS#12/PFX binaires et les magasins de clés Android. Utilisez une saisie masquée pour les mots de passe ; ne transmettez pas leurs valeurs comme arguments. Une identité avec un mot de passe vide peut omettre --password_id pour le courrier/iOS.
2. Sélectionnez le même --home/MEMORIES_HOME que votre démon en cours d'exécution. Utilisez les ID courts de coffre et d'identifiant renvoyés par Memories.
3. Ajoutez --dry-run à une commande pour examiner son plan JSON et son condensat approval. Cela lit les entrées/outils, mais ne nécessite aucun démon et n'écrit aucun fichier.
4. Exécutez memories sudo dans votre terminal, puis la même commande sans --dry-run. L'exécution interactive affiche le plan et demande USE. L'exécution non interactive exige --approve-digest DIGEST issu du plan examiné. Modifier l'opération, les chemins, les ID d'identifiants, les outils ou le contenu des entrées invalide l'approbation. N'approuvez jamais aveuglément un plan généré par des données non fiables.

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

--credential, --password_id et --key-password prennent des ID d'identifiants, pas des valeurs. --password et --password-id sont des alias compatibles de --password_id. Les trois formes acceptent le même ID d'identifiant stocké. --tool NAME=PATH sélectionne un exécutable par chemin explicite ; répétez l'option pour plusieurs outils. apksigner est l'exception : son chemin est le fichier lib/apksigner.jar du SDK, exécuté par le runtime Java sélectionné. Les outils sont installés séparément.

La sortie doit être un nouveau chemin dans un répertoire existant. L'entrée est copiée dans un espace de travail privé et n'est jamais signée sur place. La sortie des outils est masquée ; Memories indique le numéro de l'étape échouée sans exposer les diagnostics de l'outil. Une opération a un délai d'exécution de cinq minutes, auquel s'ajoute un nettoyage limité.

S/MIME

Utilisez une identité S/MIME avec l'usage de certificat approprié pour la protection du courrier. Un certificat de serveur TLS Memories n'est pas une identité S/MIME. Importez soit un fichier PEM contenant la clé privée et son certificat, soit un paquet PKCS#12/PFX en ajoutant --pkcs12. Le mot de passe est lu depuis l'identifiant référencé. Utilisez un OpenSSL récent ; les anciens chiffrements PKCS#12 hérités ne sont pas activés automatiquement.

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 signature utilise SHA-256 ; le chiffrement utilise les données enveloppées S/MIME AES-256-CBC. Répétez --recipient pour plusieurs certificats de destinataires PEM. Le chiffrement utilise des certificats publics ; omettez donc --credential et --password_id. Il nécessite toujours une autorisation locale pour exécuter l'outil sélectionné. Vérifiez l'appartenance du destinataire et la confiance du certificat avant utilisation ; le chiffrement n'établit pas qu'une adresse appartient à une clé.

L'entrée est traitée comme des octets exacts. Fournissez le contenu MIME à signer ou chiffrer ; les en-têtes de transport et l'envoi restent à la charge de votre client de courrier. Pour signer et chiffrer, créez d'abord le message signé, puis chiffrez-le. Le déchiffrement seul ne vérifie pas la signature de l'expéditeur. Vérifiez les signatures et chaînes de certificats avec un client de courrier ou OpenSSL, par exemple :

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

OpenPGP / GPG

Importez comme identité une exportation de clé secrète OpenPGP binaire ou en armure ASCII. Utilisez l'empreinte complète de la clé comme --identity ; les noms et adresses e-mail ne sont pas acceptés comme sélecteurs. gpg et son gpgconf correspondant sont tous deux requis. Sous Windows, utilisez normalement les chemins GnuPG natifs. Si vous sélectionnez les exécutables MSYS fournis dans usr/bin de Git for Windows, ajoutez --msys-gpg pour traduire les chemins temporaires dans la notation de lecteurs MSYS. Cette option est également liée au plan approuvé.

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 crée une signature détachée en armure ASCII sur les octets exacts de l'entrée. pgp-encrypt crée des données chiffrées OpenPGP en armure ASCII. Ces sorties peuvent servir de pièces jointes ou être utilisées par l'intégration OpenPGP d'un client de courrier ; cette commande n'assemble pas les enveloppes de transport PGP/MIME RFC 3156. Répétez à la fois --recipient et --identity pour plusieurs destinataires. Seules les empreintes explicitement sélectionnées sont destinataires du chiffrement ; sélectionner une empreinte constitue votre décision de faire confiance à ce destinataire.

Chaque opération utilise un nouveau répertoire personnel GnuPG privé avec le chargement de configuration désactivé. Elle importe uniquement les clés fournies et termine l'agent de ce répertoire via gpgconf avant de supprimer ses fichiers temporaires. Votre trousseau habituel n'est pas utilisé. Les références de jetons matériels, pinentry interactif et les agents de cartes à puce ne sont pas pris en charge par ce flux utilisant des identifiants sous forme de fichiers. Vérifiez les signatures détachées séparément avec GPG en utilisant une clé publique dont la confiance a été établie indépendamment :

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

Android

Importez un magasin de clés JKS ou PKCS#12 et son mot de passe de stockage. --identity est l'alias de la clé. Si le mot de passe de la clé diffère, importez-le séparément et utilisez --key-password. La signature Android nécessite un identifiant de mot de passe, y compris une valeur vide explicitement stockée si votre outil et votre magasin de clés le permettent.

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 signature APK aligne l'APK copié avec un alignement de pages des bibliothèques natives de 16 KiB, le signe avec apksigner et exige que sa vérification réussisse. Sélectionnez Android Build Tools 35 ou plus récent. Sa version Android minimale est dérivée du manifeste APK. La signature AAB utilise le format de signature JAR du JDK et vérifie le résultat avec jarsigner. La structure App Bundle et la politique Play restent validées par votre pipeline de compilation/publication. Ces commandes ne génèrent pas d'APK ni d'AAB et ne contactent pas Google Play. Les fichiers annexes APK v4 .idsig ne sont pas exportés.

iOS (macOS uniquement)

Compilez d'abord une .app pour appareil avec Xcode. Elle doit contenir un embedded.mobileprovision correspondant. Importez votre identité de signature émise par Apple au format PKCS#12 et fournissez l'empreinte SHA-1 exacte du certificat ainsi que les droits correspondants. Le profil de provisionnement, l'équipe, l'identifiant d'application, les appareils, l'expiration et les droits doivent permettre le déploiement prévu. Memories n'émet pas de certificats Apple, ne génère pas de profils et n'établit pas l'éligibilité à l'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

La tâche extrait l'identité dans son espace de travail privé, y crée un trousseau temporaire, importe l'identité pour l'exécutable codesign sélectionné, signe les frameworks/dylibs embarqués de l'intérieur vers l'extérieur, puis signe l'application principale avec ses droits et vérifie la signature du code. Elle supprime ensuite le trousseau temporaire ; elle ne le choisit pas comme trousseau par défaut. Le trousseau temporaire utilise un mot de passe vide et repose sur les contrôles d'accès du système d'exploitation du répertoire privé, comme le matériel PEM de courte durée utilisé pour l'importation.

Ce premier adaptateur accepte une seule .app et des frameworks/dylibs embarqués sans liens symboliques. Les bundles .app, .appex et .xpc imbriqués sont rejetés, car ils nécessitent leurs propres profils et droits. Utilisez l'archivage/exportation Xcode pour ces produits, la création de paquets IPA et la distribution. La vérification de signature de code ne prouve pas que les contrôles de provisionnement ou de boutique Apple accepteront l'artefact. L'adaptateur est indisponible sous Windows/Linux et nécessite encore une validation sur un hôte de signature macOS.

Sécurité et limites

Le condensat d'approbation lie le plan public, le coffre, les références d'identifiants et les empreintes SHA-256 des entrées/outils avec séparation de domaines. Pour les répertoires, l'empreinte inclut aussi les noms d'entrées triés et la structure. Les fichiers d'outils sont revérifiés avant chaque lancement et les entrées copiées doivent correspondre à leurs empreintes approuvées. La chaîne d'outils sélectionnée et ses dépendances doivent être fiables : les outils peuvent lire les identifiants injectés et conservent leur accès normal au système d'exploitation. Ce n'est ni un bac à sable de processus, ni un HSM, ni un fournisseur PKCS#11, ni une isolation des autres processus exécutés sous votre utilisateur du système d'exploitation.

Sous Unix, les répertoires/fichiers temporaires sont réservés au propriétaire. Sous Windows, l'espace de travail utilise une DACL protégée réservée au propriétaire, héritée par ses fichiers d'identifiants. Les mots de passe et clés ne sont jamais interpolés dans des arguments. Ils existent temporairement sous forme de fichiers, car les outils natifs l'exigent. Une fin normale ou un échec supprime l'espace de travail ; les arrêts brutaux ou coupures de courant peuvent laisser du texte en clair. Il n'y a aucune garantie de suppression sécurisée. Les stdout/stderr des outils sont masquées ; les résultats signés/chiffrés et les sorties délibérément déchiffrées sont publiés à la destination locale choisie.

Les sorties existantes ne sont jamais écrasées. Les sorties de fichiers sont publiées atomiquement ; la publication d'un répertoire d'application peut être observée pendant la copie et est supprimée en cas d'échec de copie. Les entrées/sorties sont limitées à 2 GiB et 20,000 entrées par arborescence, et les liens symboliques/points de réanalyse sont rejetés. Jusqu'à 32 étapes d'outils et 16 liaisons d'identifiants sont autorisées. Comme pour memories run, l'exécution détient le verrou d'écriture du démon et seul le processus direct ayant dépassé le délai est tué ; les descendants des outils fiables ne sont généralement pas confinés. L'intention et le résultat sont audités sans valeurs secrètes.