L'expiration de la clé OpenPGP renforce-t-elle la sécurité?
J'ai créé une nouvelle clé OpenPGP pour signer un package logiciel dans un référentiel source avec une date d'expiration dans trois ans. Cela semblait être une bonne mesure de sécurité, car si la clé est compromise ou volée, les dommages seront limités.
Mais j'ai pensé au jour où je devrai signer ma nouvelle clé. La signature de la nouvelle clé avec l'ancienne clé équivaut à conserver l'ancienne clé et n'ajoute donc rien à la sécurité.
La définition d'une date d'expiration améliore-t-elle la sécurité des clés? Si oui, quelle est la meilleure politique d'expiration/de remplacement des clés?
tl; dr : la date d'expiration n'est pas un mécanisme raisonnable pour protéger la clé primaire, et vous devriez avoir une révocation certificat à portée de main.
La version légèrement plus longue est que l'effet de la date d'expiration diffère entre le primaire et les sous-clés, et aussi ce que vous essayez d'éviter.
Sous-clés
Pour les sous-clés, l'effet est assez simple: après un laps de temps donné, la sous-clé expirera. Cette date d'expiration ne peut être modifiée qu'à l'aide de la clé primaire. Si un attaquant met la main sur votre sous-clé (et seulement cela), elle sera automatiquement désactivée après la date d'expiration.
La date d'expiration d'une sous-clé est un excellent outil pour annoncer que vous changez vos sous-clés sur une base régulière, et qu'il est temps pour les autres de mettre à jour votre clé après une heure donnée.
Clés primaires
Pour les clés primaires, la situation est différente. Si vous avez accès à la clé privée, vous pouvez modifier la date d'expiration comme vous le souhaitez . Cela signifie que si un attaquant a accès à votre clé privée, il peut prolonger arbitrairement la période de validité. Dans le pire des cas, vous perdez l'accès à la clé privée en même temps, alors même vous ne pouvez plus révoquer la clé publique (vous avez un certificat de révocation imprimé ou autrement hors ligne et stocké en toute sécurité, n'est-ce pas?). Une date d'expiration peut être utile dans le cas où vous perdez le contrôle de la clé (alors qu'aucun attaquant ne la contrôle). La clé expirera automatiquement après un certain temps, il n'y aura donc pas de clé inutilisable avec votre nom dessus pour toujours sur les serveurs de clés.
Récupération de clés non révoquées faibles
Pire encore, les dates d'expiration peuvent fournir un faux sentiment de sécurité. La clé sur les serveurs de clés a expiré, alors pourquoi prendre la peine de la révoquer? Il y a un grand nombre de clés RSA 512 bits bien connectées sur le réseau du serveur de clés, et probablement un nombre relativement élevé de clés DSA faibles (à cause des problèmes Debian RNG). Avec des processeurs plus rapides et possiblement de nouvelles connaissances sur les faiblesses des algorithmes, un attaquant pourrait à l'avenir être en mesure de casser la clé expirée mais non révoquée et de l'utiliser!
Garder un certificat de révocation en lieu sûr
Si vous avez un certificat de révocation et êtes sûr que vous ne perdrez jamais l'accès à la fois à votre clé privée et à votre certificat de révocation en même temps (pensez à l'incendie, au vol (physique), aux institutions officielles qui fouillent votre maison), il y a absolument aucune utilité pour fixer une date d'expiration à part une confusion possible et plus de travail pour l'étendre.
Notez qu'une date d'expiration sur la clé principale ne fait rien pour la sécurité, car toute personne qui a compromis cela pourrait toujours la prolonger de toute façon. Voir http://madduck.net/blog/2006.06.20:expiring-gpg/ .
(D'un autre côté, l'expiration des sous-clés peut être utile et l'option lors de la création de la clé définit la date sur toutes les clés.)
La définition d'une date d'expiration améliore-t-elle la sécurité des clés?
Oui. Vous avez déjà dit pourquoi aussi:
Cela semblait être une bonne mesure de sécurité, car si la clé est compromise ou volée - les dommages seront limités.
En supposant que vous êtes compromis et que la clé est volée, il est clair que votre première action serait de révoquer la clé et d'en émettre une nouvelle. Cependant, tout le monde ne vérifiera pas les clés révoquées; ils continueront à l'utiliser aveuglément jusqu'à ce qu'il devienne invalide.
De même, si vous êtes compromis, quelqu'un ne peut que prétendre être vous pour une fenêtre fixe.
Si oui, quelle est la meilleure politique d'expiration\de remplacement de clé?
Il n'y en a vraiment pas - la question est plus "qu'est-ce que je peux faire de mieux étant donné les contraintes X Y Z". Par exemple, si vous définissez la fenêtre trop petite, vous gênez les utilisateurs; cependant, trop élevé et vous ouvrez le risque s'il est compromis. Cela revient vraiment à un jugement - quelle est la sensibilité exacte de ce que vous protégez et combien de fois/est-il gênant de remplacer fréquemment les clés?