Comment ssign fonctionne, et ce qu'il fait de vos secrets

ssign est un client indépendant du service de signature cloud SimplySign. Voici ce qui quitte votre machine, ce qui est gardé sur le disque, et ce qu'il faut protéger.

Ce qui est envoyé, et à qui

Destination	Ce que ssign envoie
`cloudsign.webnotarius.pl` HTTPS	Connexion : votre e-mail et le code à 6 chiffres du moment, ainsi que les identifiants de client OAuth de la connexion web SimplySign. Ces identifiants sont des constantes de l'application, identiques pour tous les utilisateurs de SimplySign Desktop, et non votre secret. Ensuite, avec le jeton d'accès (bearer token) obtenu : la demande de votre carte et de votre certificat, puis pour chaque signature une empreinte SHA-256 calculée sur votre machine, accompagnée de votre certificat de signature.
Serveur d'horodatage `http://time.certum.pl/` par défaut, modifiable avec `--timestamp-url`	Une requête RFC 3161 contenant l'empreinte SHA-256 de la signature.
Personne	Vos fichiers, hachés localement, et votre graine TOTP, dont le code est calculé localement.

Les certificats HTTPS sont vérifiés via le magasin de certificats du système d'exploitation.

La connexion et la clé

La connexion est un flux OAuth 2.0 « authorization code » passant par le fournisseur d'identité CAS de Certum. Les identifiants sont l'e-mail et le code à 6 chiffres ; aucun mot de passe de compte n'intervient.
Elle renvoie un jeton d'accès valable environ 30 minutes. La carte SimplySign ne demande pas de PIN (pinrequired: false) : le jeton d'accès est le seul contrôle.
La clé est une RSA-4096, et la clé privée reste dans le HSM du cloud. ssign ne reçoit que des signatures.

La graine TOTP est un secret à longue durée

-O/--otp (variable d'environnement CERTUM_OTP), c'est votre graine TOTP, le secret base32 derrière votre appli d'authentification. Elle est à longue durée : quiconque l'a, avec votre e-mail, peut signer du code en votre nom, indéfiniment, jusqu'à ce que vous régénériez le QR code SimplySign. Traitez-la comme une clé privée.

Jamais en argument de ligne de commande : elle finit dans l'historique du shell et dans la liste des processus. Utilisez la variable d'environnement.
Préférez -T/--token (un code à usage unique) pour signer à la main en local : la graine ne quitte alors jamais votre appli d'authentification.
En CI, stockez-la comme secret d'environnement protégé avec relecteurs requis (comment faire), pas comme un simple secret de dépôt.
En cas de fuite, changez-la : régénérez le QR code chez Certum.

L'e-mail du compte n'est pas sensible. Le code à 6 chiffres expire en 30 secondes environ et présente peu de risque.

En mémoire, la commande garde la graine ou le code dans un tampon effacé dès qu'il ne sert plus. Cela ne peut rien contre une exposition antérieure au démarrage de ssign : une valeur passée avec --otp est visible dans /proc/<pid>/cmdline, et une valeur passée par CERTUM_OTP dans /proc/<pid>/environ.

Le cache de session

Pour éviter une seconde connexion (Certum n'accepte chaque code qu'une fois), la commande ssign et le module PKCS#11 enregistrent la session après la connexion, et la réutilisent aux exécutions suivantes.

Où : $XDG_RUNTIME_DIR/ssign/session.json ; si XDG_RUNTIME_DIR n'est pas défini, $HOME/.cache/ssign/session.json ; sinon ssign/session.json dans le dossier temporaire du système.
Quoi : l'e-mail du compte, le jeton d'accès, une heure d'expiration, le numéro de carte et le certificat de signature. Ni la graine ni le code ne sont écrits.
Combien de temps : ssign fait confiance à un jeton enregistré pendant 20 minutes, en deçà de sa durée de vie d'environ 30 minutes, et se reconnecte quand il reste moins de 2 minutes.
Permissions : sur les systèmes Unix, le dossier est créé en mode 0700 et le fichier en 0600, lisibles par votre seul utilisateur.
Un cache enregistré pour une autre adresse e-mail, expiré ou illisible est ignoré, et ssign se reconnecte.

Quiconque peut lire session.json peut signer en votre nom jusqu'à l'expiration du jeton. Gardez-le en tête sur une machine partagée.

Ce que contient la signature

ssign construit un SignedData PKCS#7 Authenticode standard : l'empreinte Authenticode SHA-256 du fichier, l'heure de signature, la description et l'URL facultatives (-n, -u), la signature RSA du cloud, votre certificat et l'intermédiaire Certum « Code Signing 2021 CA », et le jeton d'horodatage RFC 3161. Il est intégré à la table des certificats du fichier PE, dont la somme de contrôle est mise à jour. L'empreinte envoyée au cloud est le SHA-256 des attributs signés qui portent l'empreinte du fichier.

Le protocole SimplySign

ssign parle directement le protocole du cloud :

Cloud CertumConnexionconnexion OAuth avec votre e-mail et un code à usage unique à 6 chiffres → jeton d'accès
Cloud CertumRécupération de la cartenuméro de carte et certificat de signature
Votre machineHachageempreinte Authenticode SHA-256 de chaque fichier
Cloud CertumDemande de signaturel'empreinte et le certificat → tâche asynchrone
Cloud CertumAttente du résultat→ signature RSA-4096
Votre machineAssemblagePKCS#7 + chaîne de certificats + horodatage RFC 3161, écrits dans le fichier

Le protocole a été reconstitué par rétro-ingénierie à partir de l'installation sous licence de SimplySign Desktop 2.9.14 de l'auteur, à des fins d'interopérabilité, avec un proxy qui enregistrait la structure des requêtes en masquant chaque valeur : aucun jeton, code, PIN ni signature n'a été écrit sur le disque. Tout le flux est du HTTPS simple, sans étape d'activation cryptographique : le contrôle de session repose sur le jeton d'accès OAuth. Le module PKCS#11 de SimplySign Desktop n'est qu'une fine couche qui relaie vers l'application de bureau en cours d'exécution, et c'est pourquoi il ne peut pas signer seul. La référence complète, avec les points d'accès et les fausses pistes : docs/simplysign-protocol.md (en anglais).