Je dirais que leur suggestion n'est pas très solide, à moins que vous n'utilisiez des tailles de clé horriblement petites - auquel cas vous avez un problème complètement différent.

Une clé de 2048 bits, par la plupart des estimations, vous gardera en sécurité au moins jusqu'en 2020, sinon plus longtemps. Si vous utilisez des clés de 1024 bits ou moins, vous êtes en dessous de la norme et je recommande la mise à jour immédiate vers 2048 bits. Si vous utilisez actuellement des clés de 1536 bits, vous devriez être en sécurité pendant un an ou deux.

Bien sûr, tout cela est académique. La probabilité que quelqu'un soit capable (ou enclin) à déchiffrer votre clé SSL de 1024 bits en un an est extrêmement faible.

Comme mentionné dans la question que vous avez liée, il y a des avantages et des inconvénients.

• Donne moins de temps à un attaquant pour casser la clé. Un peu discutable si vous utilisez de toute façon des tailles de clé raisonnables.
• Arrête tous les malfaiteurs qui pourraient avoir compromis votre clé privée. Peu probable, mais inconnu.
• Vous donne la possibilité d'augmenter la taille de votre clé pour être en avance sur la courbe.

Inconvénients

• Ne vous donne pas vraiment de protection concrète contre le piratage de clés, sauf si vous utilisez des clés terriblement petites.
• Les plugins de vérification SSL / anti-MitM pour les navigateurs peuvent alerter l'utilisateur que le la clé a changé. C'est, à mon avis, un faible inconvénient - la plupart des utilisateurs ne l'utiliseront pas.
• Cela pourrait provoquer des avertissements temporaires en relation avec des politiques et des mises en œuvre HSTS plus strictes.
• Cela demande du travail. Vous pourriez faire autre chose.

Donc, des deux côtés, il y a des raisons faibles, et quelques cas secondaires que vous devrez peut-être considérer. Je pencherais légèrement vers l'angle «ne le fais pas sauf si tu as besoin de», tant que tu utilises des clés de 2048 bits ou plus.

Le plus important est de leur demander pourquoi ils pensent que c'est nécessaire - il se peut que vous ayez une raison liée à l'infrastructure pour mettre à jour les clés que nous ne connaissons pas. S'ils ne parviennent pas à trouver un argument solide ("pourquoi pas?" N'est pas vraiment valable), ils devraient probablement réévaluer leurs conseils.

Changer la clé privée n'est pas une meilleure pratique, c'est une pratique répandue ; cela a en fait très peu à voir avec la sécurité, et beaucoup à voir avec la manière dont les autorités de certification gèrent les renouvellements de certificats, c'est-à-dire la plupart du temps comme un nouveau certificat, avec une nouvelle génération de clé privée. Il est plus simple, côté CA , de ne rien faire de spécial pour un renouvellement. D'où l'habitude de changer les clés.

Les mêmes administrateurs système n'insisteront pas pour générer de nouvelles clés chaque année pour leurs serveurs SSH, même si la situation est similaire, à partir d'un point de sécurité de vue. Ou, plus précisément, changer une clé de serveur SSH est un peu gênant car cela casse les fichiers .ssh / known_hosts des clients. Par conséquent, il est habituel d'éviter de modifier les clés du serveur SSH. Ainsi, les clés de serveur SSH ont une longue durée de vie. Personne ne manque vraiment un battement de cœur à ce sujet. Pourquoi devraient-ils s'inquiéter des clés SSL de puissance cryptographique similaire?

La meilleure pratique consiste à changer la clé lorsque les progrès technologiques ont rendu votre clé quelque peu vulnérable, en tenant compte de la paranoïa générale (souvent appelé «pour des raisons de conformité»); vous considérez donc que pour le moment, en 2013, une clé RSA de 1024 bits devrait être remplacée par une clé plus longue, même si nous sommes encore loin de pouvoir casser une telle clé. Si votre clé RSA est de 1536 bits ou plus, il n'y a aucune raison cryptographique d'en créer une nouvelle (mais, là encore, il est peut-être juste plus pratique de la changer, côté CA).

La réponse n'est ni technique ni cryptographique, elle concerne les personnes. Avec des choses comme les changements de travail (entendu parler d'administrateurs mécontents?), Les migrations de serveurs, les tests DR, les sauvegardes et autres clés privées peuvent devenir un peu exposées.

Compte tenu de ce qui précède, le renouvellement des clés est une bonne pratique de sécurité.

Ne vous inquiétez pas si quelqu'un factorise votre clé RSA. La factorisation d'une clé RSA de 1024 bits peut être possible pour les adversaires au niveau de l'état, mais même pour eux, ce n'est probablement pas rentable. La factorisation des clés 2048 bits ne sera probablement pas possible avant quelques décennies.

Je m'inquiéterais principalement du vol de votre clé privée lors d'un compromis de serveur. Le gain en cas de compromis passés n'est pas clair, car l'attaquant peut avoir des logiciels malveillants persistants sur votre serveur. Vous devrez donc réinstaller le serveur pour sécuriser la nouvelle clé.

Un autre problème est que certaines suites SSL faibles (principalement la famille de chiffrement RSA ) utilisent votre long terme clé pour la confidentialité, et pas seulement pour l'authentification. Avec ceux-ci, un compromis de la clé de votre serveur permet le décryptage de toutes les communications SSL passées avec votre serveur qui utilisait une suite aussi faible. L'utilisation d'une nouvelle clé et la suppression sécurisée de l'ancienne limite l'impact d'une telle attaque.

Donc, si votre serveur a toujours ces suites activées, je recommande fortement de changer la clé régulièrement.

• Avez-vous changé vos clés après HeartBleed?
• Que font les techniciens de votre centre de données avec des disques durs défectueux?
• Quelqu'un a-t-il quitté l'organisation opérationnelle au cours de la dernière année ?
• À quand remonte la dernière rotation des mots de passe administrateur et des clés ssh?

Toutes ces questions devraient vous amener à réfléchir à l'intégrité de vos clés. Je ne dis pas qu'il est probable qu'ils soient compromis ou que quiconque pourra en abuser. J'essaie de vous amener à réfléchir aux raisons pour lesquelles vous pourriez vouloir les faire pivoter.

La rotation des clés devrait être très facile et constitue une bonne hygiène de sécurité. Si vous ne le faites pas parce que c'est difficile, c'est un problème sérieux. Construisez les outils et les processus pour vous faciliter la tâche. Si vous ne le faites pas, vous finirez par échouer dans la rotation des choses beaucoup plus importantes.

Plus vous utilisez une clé, plus vous donnez de temps à un attaquant. Même si la rupture de 2048 bits n'est pas considérée comme possible avec la technologie actuelle, être extrêmement prudent et remplacer la clé n'est pas du tout une mauvaise chose.

De plus, quelqu'un aurait pu obtenir votre clé privée, sans que vous ayez pu la détecter. S'il ne peut pas répéter l'action, alors l'avantage du renouvellement est très clair.

Bien que je reconnaisse qu'il y a peu de raisons techniques de générer de nouvelles clés chaque fois que vous renouvelez un certificat, je ne mettrais pas immédiatement au défi votre équipe / responsables de sécurité et ne les appellerais pas.

Il peut y avoir des raisons non techniques qui sont tout aussi valables pour générer de nouvelles clés. Par exemple, dans une grande organisation où il existe différents niveaux de centralisation informatique, de compétences, de procédures et de bonnes pratiques, une zone de gestion de la sécurité centralisée peut exiger de telles pratiques pour aider à atténuer certains des risques. maniable. Si des procédures plus complexes peuvent être plus correctes d'un point de vue technique, elles sont plus difficiles à documenter et font qu'il est plus difficile pour le personnel de savoir qu'il les suit correctement. À condition que la pratique ne crée pas de frais généraux importants, il peut être plus facile d'adopter et de maintenir l'approche plus simple toujours X.

Pensez-y sous un autre angle. Tous les membres de votre organisation qui ont la responsabilité de gérer les certificats ont-ils la même conscience et la même compréhension des problèmes que vous et sont-ils aussi consciencieux / dévoués? Quel est le niveau de rotation du personnel et dans quelle mesure faut-il s'inquiéter de la quantité de données sensibles auxquelles les anciens employés peuvent avoir accès, etc.

Chaque fois que l'on considère la sécurité, le facteur humain est presque toujours aussi important ou plus important que les seuls aspects techniques. Les politiques et procédures doivent tenir compte de l'élément humain et essayer de garantir que ces politiques et procédures sont structurées de manière à permettre au personnel de faire ce qu'il faut, même s'il ne comprend pas parfaitement pourquoi il doit le faire.

SP 800-57, partie 1 révisée, recommandation pour la gestion des clés

Les recommandations du NIST sur les cryptopériodes RSA semblent durer de 1 à 2 ans.

C'est vraiment la même chose que de changer de mot de passe. Si quelqu'un est en train de déchiffrer votre mot de passe lorsque vous le modifiez, il devra recommencer. Ou si le mot de passe, ou la clé privée, a été volé, le renouvellement invaliderait leur clé volée (en supposant qu'ils ne peuvent pas facilement la voler à nouveau).

Cela pourrait être une bonne habitude de changer la clé privée chaque année ou toutes les quelques années juste pour que vous sachiez qu'il ne cassera rien lorsque vous aurez besoin de le changer, mais ce n'est pas nécessaire pour la sécurité du certificat en soi.

Plusieurs personnes ont évoqué le fait que les clés d'hôte ssh sont rarement tournées comme argument pour ne pas faire pivoter les clés ssl. Cela semble être un autre problème à résoudre. (Je m'excuse pour une réponse légèrement hors sujet, mais plusieurs personnes ici l'ont mentionnée, donc cela semble approprié)

Voir ma réponse ci-dessus pour pourquoi on pourrait souhaiter faire pivoter les clés.

Ce qui suit sera particulièrement utile pour tous ceux qui, pour des raisons de conformité, doivent faire pivoter les clés d'hôte ssh, mais qui s'inquiètent de l'impact de la convivialité sur les utilisateurs finaux.

1) Déployez un ssh_ca (Instructions remarquablement complètes dans man ssh-keygen)

  ssh-keygen -f ssh_ca -b 4096  

2) Distribuez le certificat à vos utilisateurs: Ajoutez une ligne d'autorité de certification à ~ / .ssh / known_hosts

  @ cert-authority * .domain.name ssh-rsa AAAAB3 [...] == Comment  

3) Signez vos clés d'hôte (assurez-vous de limiter chacune à un hôte individuel)

  ssh-keygen -s ssh_ca -I host.domain.name -h -n host.domain .name -V + 52w /etc/ssh/ssh_host_rsa_key.pub  

4) Configurer le (s) serveur (s) pour présenter le certificat (/ etc / ssh / sshd_config):

  HostCertificate / etc / ss h / ssh_host_rsa_key-cert.pub  

Toute clé d'hôte signée par l'AC est désormais approuvée par le client (plus d'accepter aveuglément une clé sig la première fois que vous vous connectez)

Le roulement de la clé d'hôte peut désormais être effectué sans interruption pour les clients. La signature de clé peut être intégrée au processus de compilation / orchestration de l'hôte.

Ceci est une bonne référence. Ce projet a créé des outils utiles pour l'utilisation de ssh_ca pour un accès utilisateur à expiration automatique.