E-Mail-Kryptografie und Anwendungssignierung

memories crypto verwendet verschlüsselte Zugangsdaten mit vertrauenswürdigen Signierwerkzeugen auf dem Desktop. Es unterstützt S/MIME- und OpenPGP-E-Mail-Operationen, die Signierung von Android-APK/AAB sowie die Signierung provisionierter iOS-.app-Pakete auf macOS. Es versendet keine E-Mails und veröffentlicht keine Apps. Diese Operationen werden über den lokalen Daemon mit sudo im Terminal ausgeführt. Sie sind weder über MCP noch über die mobile FFI verfügbar. Aktualisieren Sie sowohl die CLI als auch den Daemon und starten Sie den Daemon neu, bevor Sie diese Befehle verwenden; ältere Daemons erkennen die neue Operation nicht.

Prüfen und ausführen

Installieren Sie die erforderlichen Werkzeuge und importieren Sie die Identität und ihr Passwort als separate Zugangsdaten. credential import akzeptiert binäre PKCS#12/PFX-Dateien und Android-Keystores. Verwenden Sie für Passwörter eine verdeckte Eingabe; übergeben Sie ihre Werte nicht als Argumente. Bei einer Identität mit leerem Passwort kann --password_id für E-Mail/iOS entfallen.
Wählen Sie dieselbe Einstellung für --home/MEMORIES_HOME wie bei Ihrem laufenden Daemon. Verwenden Sie die kurzen Tresor- und Zugangsdaten-IDs, die Memories zurückgibt.
Fügen Sie einem Befehl --dry-run hinzu, um seinen JSON-Plan und den approval-Digest zu prüfen. Dabei werden Eingaben/Werkzeuge gelesen, aber kein Daemon benötigt und keine Dateien geschrieben.
Führen Sie memories sudo in Ihrem Terminal aus und anschließend denselben Befehl ohne --dry-run. Die interaktive Ausführung zeigt den Plan an und fordert zur Eingabe von USE auf. Die nicht interaktive Ausführung erfordert --approve-digest DIGEST aus dem geprüften Plan. Änderungen an der Operation, den Pfaden, Zugangsdaten-IDs, Werkzeugen oder Eingabeinhalten machen die Freigabe ungültig. Genehmigen Sie niemals ungeprüft einen Plan, der aus nicht vertrauenswürdigen Daten erzeugt wurde.

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

--credential, --password_id und --key-password erwarten Zugangsdaten-IDs, keine Werte. --password und --password-id sind kompatible Aliase für --password_id. Alle drei Schreibweisen akzeptieren dieselbe gespeicherte Zugangsdaten-ID. --tool NAME=PATH wählt eine ausführbare Datei über einen expliziten Pfad aus; wiederholen Sie die Option für mehrere Werkzeuge. apksigner ist die Ausnahme: Sein Pfad ist die SDK-Datei lib/apksigner.jar, die von der ausgewählten Java-Laufzeit ausgeführt wird. Die Werkzeuge werden separat installiert.

Die Ausgabe muss ein neuer Pfad in einem vorhandenen Verzeichnis sein. Die Eingabe wird in einen privaten Arbeitsbereich kopiert und niemals am ursprünglichen Ort signiert. Werkzeugausgaben werden unterdrückt; Memories meldet die Nummer des fehlgeschlagenen Schritts, ohne Diagnoseausgaben der Werkzeuge offenzulegen. Für eine Operation gilt eine Ausführungsfrist von fünf Minuten, zuzüglich einer zeitlich begrenzten Bereinigung.

S/MIME

Verwenden Sie eine S/MIME-Identität mit der passenden Zertifikatsverwendung zum E-Mail-Schutz. Ein Memories-TLS-Serverzertifikat ist keine S/MIME-Identität. Importieren Sie entweder eine PEM- Datei, die den privaten Schlüssel und sein Zertifikat enthält, oder ein PKCS#12/PFX-Paket und übergeben Sie --pkcs12. Das Passwort wird aus den referenzierten Zugangsdaten gelesen. Verwenden Sie eine aktuelle OpenSSL-Version; ältere Legacy-PKCS#12-Chiffren werden nicht automatisch aktiviert.

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

Die Signierung verwendet SHA-256; die Verschlüsselung verwendet S/MIME Enveloped Data mit AES-256-CBC. Wiederholen Sie --recipient für mehrere PEM-Empfängerzertifikate. Die Verschlüsselung verwendet öffentliche Zertifikate, lassen Sie deshalb --credential und --password_id weg. Zum Ausführen des ausgewählten Werkzeugs ist weiterhin eine lokale Autorisierung erforderlich. Prüfen Sie vor der Verwendung, wem der Empfänger gehört und ob das Zertifikat vertrauenswürdig ist; die Verschlüsselung bestätigt nicht, dass eine Adresse zu einem Schlüssel gehört.

Die Eingabe wird als unveränderte Bytefolge verarbeitet. Stellen Sie den MIME-Inhalt bereit, den Sie signieren oder verschlüsseln möchten; Transport-Header und Versand bleiben Aufgabe Ihres E-Mail-Clients. Zum Signieren und Verschlüsseln erstellen Sie zuerst die signierte Nachricht und verschlüsseln sie anschließend. Die Entschlüsselung allein prüft nicht die Signatur eines Absenders. Prüfen Sie Signaturen und Zertifikatsketten mit einem E-Mail-Client oder OpenSSL, beispielsweise:

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

OpenPGP / GPG

Importieren Sie einen ASCII-armierten oder binären OpenPGP-Export eines geheimen Schlüssels als Identität. Verwenden Sie den vollständigen Schlüsselfingerabdruck als --identity; Namen und E-Mail-Adressen werden nicht als Auswahlkriterien akzeptiert. Sowohl gpg als auch das dazu passende gpgconf sind erforderlich. Verwenden Sie unter Windows normalerweise native GnuPG-Pfade. Wenn Sie die MSYS-Programme auswählen, die in usr/bin von Git for Windows mitgeliefert werden, fügen Sie --msys-gpg hinzu, um temporäre Pfade in die MSYS-Laufwerksnotation umzuwandeln. Diese Option wird ebenfalls in den genehmigten Plan eingebunden.

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 erstellt eine armierte, abgetrennte Signatur über die unveränderten Eingabebytes. pgp-encrypt erstellt armierte, OpenPGP-verschlüsselte Daten. Diese Ausgaben können als Anhänge oder durch die OpenPGP-Integration eines E-Mail-Clients verwendet werden; dieser Befehl erstellt keine PGP/MIME-Transporthüllen gemäß RFC 3156. Wiederholen Sie sowohl --recipient als auch --identity für mehrere Empfänger. Es wird nur für explizit ausgewählte Fingerabdrücke verschlüsselt; mit der Auswahl eines Fingerabdrucks entscheiden Sie, diesem Empfänger zu vertrauen.

Jede Operation verwendet ein neues privates GnuPG-Home-Verzeichnis, wobei das Laden von Konfigurationen deaktiviert ist. Sie importiert nur die bereitgestellten Schlüssel und beendet den Agenten dieses Home-Verzeichnisses über gpgconf, bevor sie ihre temporären Dateien löscht. Ihr normaler Schlüsselbund wird nicht verwendet. Hardware- Token-Stubs, interaktive pinentry und Smartcard-Agenten werden von diesem Arbeitsablauf mit dateibasierten Zugangsdaten nicht unterstützt. Prüfen Sie abgetrennte Signaturen separat mit GPG und einem unabhängig als vertrauenswürdig eingestuften öffentlichen Schlüssel:

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

Android

Importieren Sie einen JKS- oder PKCS#12-Keystore und sein Store-Passwort. --identity ist der Schlüssel- Alias. Falls das Schlüsselpasswort abweicht, importieren Sie es separat und verwenden Sie --key-password. Die Android-Signierung erfordert gespeicherte Passwort-Zugangsdaten, einschließlich eines explizit gespeicherten leeren Werts, falls Ihr Werkzeug und Keystore dies erlauben.

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

Die APK-Signierung richtet die kopierte APK mit einer Seitenausrichtung von 16 KiB für native Bibliotheken aus, signiert sie mit apksigner und setzt eine erfolgreiche Verifikation voraus. Wählen Sie Android Build Tools 35 oder neuer. Die minimale Android-Version wird aus dem APK-Manifest abgeleitet. Die AAB-Signierung verwendet das JAR-Signierformat des JDK und prüft das Ergebnis mit jarsigner. Die App-Bundle-Struktur und die Play-Richtlinien werden weiterhin von Ihrer Build-/Release-Pipeline validiert. Diese Befehle erzeugen keine APKs oder AABs und kontaktieren Google Play nicht. APK-v4-.idsig-Begleitdateien werden nicht exportiert.

iOS (nur macOS)

Erstellen Sie zuerst mit Xcode eine .app für ein Gerät. Sie muss eine passende embedded.mobileprovision enthalten. Importieren Sie Ihre von Apple ausgestellte Signieridentität als PKCS#12 und geben Sie den exakten SHA-1-Fingerabdruck des Zertifikats sowie passende Entitlements an. Das Provisionierungsprofil, das Team, die Anwendungskennung, die Geräte, das Ablaufdatum und die Entitlements müssen die beabsichtigte Bereitstellung erlauben. Memories stellt keine Apple- Zertifikate aus, erzeugt keine Profile und bestätigt keine Eignung für den 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

Der Auftrag extrahiert die Identität in seinem privaten Arbeitsbereich, erstellt dort einen temporären Schlüsselbund, importiert die Identität für das ausgewählte codesign-Programm, signiert eingebettete Frameworks/dylibs von innen nach außen und anschließend die Haupt-App mit Entitlements und prüft die Codesignatur. Danach löscht er den temporären Schlüsselbund; er legt ihn nicht als Ihren Standardschlüsselbund fest. Der temporäre Schlüsselbund verwendet ein leeres Passwort und verlässt sich auf die Betriebssystem-Zugriffskontrollen des privaten Verzeichnisses, genau wie das kurzlebige PEM-Material, das für den Import verwendet wird.

Dieser erste Adapter akzeptiert eine einzelne .app und eingebettete Frameworks/dylibs ohne symbolische Links. Verschachtelte .app-, .appex- und .xpc-Bundles werden abgelehnt, weil sie eigene Profile und Entitlements benötigen. Verwenden Sie für solche Produkte, die IPA-Paketierung und die Verteilung die Archiv-/Exportfunktionen von Xcode. Die Codesignaturprüfung beweist nicht, dass Apples Provisionierungs- oder Store-Prüfungen das Artefakt akzeptieren werden. Der Adapter ist unter Windows/Linux nicht verfügbar und muss weiterhin auf einem macOS-Signierhost validiert werden.

Sicherheit und Grenzen

Der Freigabe-Digest bindet den öffentlichen Plan, den Tresor, die Zugangsdatenreferenzen und domänenseparierte SHA-256-Fingerabdrücke der Eingaben/Werkzeuge. Bei Verzeichnissen enthält der Fingerabdruck auch sortierte Eintragsnamen und die Struktur. Werkzeugdateien werden vor jedem Start erneut geprüft, und kopierte Eingaben müssen ihren genehmigten Fingerabdrücken entsprechen. Die ausgewählte Werkzeugkette und ihre Abhängigkeiten müssen vertrauenswürdig sein: Werkzeuge können eingespeiste Zugangsdaten lesen und behalten ihren normalen Betriebssystemzugriff. Dies ist keine Prozess-Sandbox, kein HSM, kein PKCS#11-Anbieter und keine Isolation von anderen Prozessen, die unter Ihrem Betriebssystembenutzer laufen.

Unter Unix sind temporäre Verzeichnisse/Dateien nur für den Eigentümer zugänglich. Unter Windows verwendet der Arbeitsbereich eine geschützte DACL, die nur dem Eigentümer Zugriff gewährt und von seinen Zugangsdaten-Dateien geerbt wird. Passwörter und Schlüssel werden niemals in Argumente eingesetzt. Sie liegen vorübergehend als Dateien vor, weil die nativen Werkzeuge sie benötigen. Bei normalem Abschluss oder Fehler wird der Arbeitsbereich entfernt; Abstürze oder Stromausfälle können Klartext zurücklassen. Es gibt keine Garantie für sicheres Löschen. stdout/stderr der Werkzeuge werden unterdrückt; signierte/verschlüsselte Ergebnisse und bewusst entschlüsselte Ausgaben werden am gewählten lokalen Ziel veröffentlicht.

Vorhandene Ausgaben werden niemals überschrieben. Dateiausgaben werden atomar veröffentlicht; die Veröffentlichung eines App- Verzeichnisses kann während des Kopierens beobachtet werden und wird bei einem Kopierfehler entfernt. Eingaben/Ausgaben sind auf 2 GiB und 20,000 Einträge pro Verzeichnisbaum begrenzt, und symbolische Links/Reparse-Punkte werden abgelehnt. Bis zu 32 Werkzeugschritte und 16 Zugangsdaten- Bindungen sind erlaubt. Wie bei memories run hält die Ausführung die Schreibsperre des Daemons, und bei Zeitüberschreitung wird nur der direkt gestartete Prozess beendet; Nachfolgeprozesse vertrauenswürdiger Werkzeuge werden im Allgemeinen nicht eingeschränkt. Absicht und Ergebnis werden ohne geheime Werte protokolliert.