Penser qu’une simple révocation de certificat permettrait de résoudre le problème, c’est tout simplement ne pas comprendre les mécanismes qui sont en jeu.

Les certificats ont pour but de créer une hiérarchie de confiance. Il faut une autorité racine, qui va elle-même “certifier” des autorités intermédiaires (qui peuvent éventuellement certifier d’autres autorités intermédiaires), pour certifier une autorité finale (ici, l’éditeur du driver).

Un certificat, c’est fait pour gérer l’identification, l’authentification, la signature et la non répudiation. Ce n’est pas fait pour interdire un truc sous prétexte qu’il y a une faille de sécurité. Et surtout, c’est fait pour que hiérarchiquement, chacun prenne ses responsabilités.

Si une autorité présente une défaillance, alors son autorité “de tutelle” peut la révoquer. Et l’autorité de tutelle peut elle-même être révoquée si elle ne fait pas correctement son travail et ainsi de suite jusqu’à remonter au certificat racine (qui lui, ne peut pas se révoquer).

Utiliser un certificat pour gérer la révocation des drivers, cela sous-entend donc

• détourner l’usage des certificats ;


• générer UN certificat par VERSION de CHAQUE driver ;


• que CHAQUE éditeur devienne autorité intermédiaire, et gère donc pleins de certificats ;


• que CHAQUE éditeur face le nécessaire pour révoquer un certificat quand c’est nécessaire (car si on a une chaine A -> B-> C-> D-> driver, seule l’autorité D peut révoquer le driver ! C, B et A ne le peuvent pas) ;


• que CHAQUE éditeur pourrait au final approuver n’importe quel driver (y compris ceux qui ne sont pas les siens) ==> grosse faille de sécurité

Ne pas se baser sur les certificats pour gérer une liste de pilotes malveillants, c’est permettre à une seule entité (ici Microsoft) d’agir dès qu’une faille est détectée, sans avoir besoin d’attendre une action de la part de l’éditeur correspondant.

Maintenant, se pose le problème de la mise à jour. Mais si Microsoft ne le fait pas (alors qu’il a tout intérêt d’un point de vue sécurité), il est illusoire de penser que les éditeurs le feront d’eux-mêmes…

(quote:2099596:alex.d.)
La signature des drivers certifie que le driver est digne de confiance. Le driver n’est plus digne de confiance ? On révoque son certificat. Je ne vois pas où est le détournement, ça me semble au contraire couler de source.

Parce que celui qui va révoquer n’est pas celui qui va signer. Je l’ai précisé dans mon précédent message (partie que tu ne commentes absolument pas alors que ça fout justement en l’air l’utilisation des certificats pour un tel usage). Lorsqu’une autorité révoque un certificat, c’est qu’il y a un souci avec ce certificat (volé, fuite de la clé privée, ou que sais-je). Celui qui révoque est donc celui qui a émit le certificat. La situation est ici fort différente, puisque Microsoft, sur la base des failles découvertes, décide de bloquer un driver malveillant ou présentant une faille de sécurité. Microsoft, pas l’éditeur dudit driver.

Oui, et ? Un certificat, c’est un fichier, rien de plus. Faut un peu démystifier le truc, hein. Si tu gardes une trace de ce que tu signes (en général, c’est conseillé), tu as déjà un autre fichier pour chaque driver : le driver lui-même.

C’est une complexité supplémentaire sous estimé (gestion de la clé privée oublié par exemple), mais surtout inutile car inefficace et non adapté techniquement.

Ah bon ? Tu sais que tu peux générer des certificats intermédiaires sans déléguer pour autant. D’ailleurs, actuellement c’est déjà le cas, MS ne signe pas avec la clef racine, ils possèdent donc eux-même un certificat intermédiaire signé par eux-mêmes.

Il va falloir m’expliquer l’intérêt d’avoir un certificat intermédiaire s’il n’y a aucune délégation

Et heureusement que Microsoft ne signe pas avec son certificat racine. Le certificat racine (enfin sa clé privée surtout) ne sert que dans très peu d’occasion (pour des raisons de sécurité) et est conservé à part (et normalement, hors ligne pour une sécurité maximum).

Maintenant, un éditeur se retrouvera de facto autorité intermédiaire, puisqu’il devrait gérer les certificats de ses propres drivers. C’est une complexité supplémentaire qui n’apporte absolument rien, car comme dit dans mon message précédant, le certificat d’un driver ne pourra être révoqué que par le certificat de son éditeur, pas par l’autorité qui a certifié l’éditeur. C’est ainsi que fonctionne la hiérarchie des certificats et le principe de révocation.

En attendant, tu fais tout un laïus en essayant de montrer que si c’est possible et techniquement faisable, en omettant clairement de contrer les deux arguments qui remettent en cause même l’utilisation des certificats pour cet usage :

• l’argument qui dit que seul l’éditeur peur révoquer ses drivers,


• ainsi que les problèmes de sécurité, puisqu’un éditeur pourrait potentiellement signer un driver en se faisant passer pour un autre (si la gestion des autorités de certification est mal faite, via des restrictions sur les subjectName, ce qui est relativement peu courant).

(quote:2099622:alex.d.)
C’est déjà Microsoft qui signe les drivers via WHQL. Donc le même Microsoft peut les révoquer.

Raté.

Microsoft peut les signer, mais des éditeurs tiers aussi. Et cela ne concerne que les drivers en mode noyau.

Pour des drivers en mode utilisateur (comme les imprimantes), c’est encore différents.

On ne m’enlèvera pas de l’idée que le mécanisme de signature des drivers, si dès le départ il ne prévoit pas la révocation, c’est plutôt stupide.

Encore une fois, le mécanisme de signature des drivers n’est pas fait pour ça. Il est fait pour garantir la provenance et l’authenticité des drivers, pas pour gérer la sécurité (absence de faille) des drivers.