Si tu autorises un accès à la carte mère, tu es juste mort d'un point de vue sécu. Non pas que ça va forcément te permettre de lancer les programmes que tu veux en 10 minutes sur toutes les plateformes, mais tu vas pouvoir faire tout un tas de choses potentiellement intéressantes pour un attaquant, au niveau de la confidentialité, de l'intégrité ou juste de la disponibilité de sous-systèmes.
Dans la modélisation des menaces, il y a très peu de cas pour lesquels un fabriquant de carte mère de PC classique et encore moins un utilisateur souhaiterait être résistant dans certains domaines face à un accès direct à la carte mère. Ça peut exister, mais dans des cas spéciaux, pas vraiment dans le cas général. Dans le cas général on peut considérer que la personne qui accède à la carte mère possède le pc (soit qu'elle le possède au sens légal, soit qu'elle le "own")
Dans une modélisation des menaces qui prend ce fait en compte, il est totalement possible de concevoir, sans surcoût exorbitant, des mécanismes de boot sécurisés qui ne se résument pas simplement à la construction de prisons dorées sous iMarque, sous l'empire des Fenêtres, ni sous big brotheria Googlesque. Il suffit de permettre de rendre accessible par un jumper une zone normalement read-only, de manière à ce que l'utilisateur puisse installer ses propres clefs racines si l'envie lui prend.
On n'a donc pas dans l'absolu à subir le prix démesuré de la perte de la possibilité par l'utilisateur d'installer ce qu'il désire dès que le système dispose d'un boot sécurisé.
Malheureusement en pratique certaines boites ont tout intérêt à ce que les boots sécurisés n'incluent pas cette possibilité (et je parle d'informatique généraliste, pas de truc dédiée multimédia ni de console de jeux-vidéos). Toutes leurs docs de référence et de conformité seront orientés pour que les OEM fassent des cartes avec impossibilité de maj les clefs racines (rien que la simple omission serait efficace en la matière, et ne parlons pas d'une rédaction astucieuse par un type ayant explicitement ça en tête) et même de plus de préférence avec impossibilité de désactiver le boot "sécurisé", que l'on devrait alors plutôt renommer en boot de mise sous-tutelle (si vous avez une expression encore plus stylée en tête, merci de la proposer en réponse à ce commentaire). Lesdites boites se défendront d'avoir cette démarche et répondront à toute critique en disant qu'ils n'interdisent pas aux OEM d'implémenter aussi un autre mécanisme autorisant le démarrage d'OS "alternatifs" (si possible en sous-entendant au passage qu'ils ne pourront pas profiter de boot sécu ou alors dans des conditions faisant passer Windows pour un système ouvert)
La sécurité et l'indépendance vont de pair. La capacité souveraine des possesseurs d'infrastructure numérique de régler ou faire régler par la personne de leur choix les problèmes dans les logiciels qu'ils utilisent sans pour autant être soumis au bon vouloir absolu de fournisseurs imposés (cela peut éventuellement nécessiter des moyens importants) est primordiale si l'on souhaite avoir de réelles capacités de défense, et il est tout autant primordial que cela ne nécessite pas la désactivation d'autres aspects de sécurité. Cela peut valoir pour les individus, pour les organisations, pour les états, pour tout le monde. Dans la guerre contre les ordinateurs universels qui se prépare, il est important d'exiger que les fonctionnalités du matériel ne soient pas réservées aux seuls empires sans âmes rêvant de dupliquer des modèles commerciaux de vendeurs de gadgets de luxe.
[^] # Re: Sécurité absolue
Posté par Guillaume Knispel . En réponse à la dépêche Le noyau Linux 3.2 est disponible. Évalué à 8.
Ça dépend de la définition de "sécurité".
Si tu autorises un accès à la carte mère, tu es juste mort d'un point de vue sécu. Non pas que ça va forcément te permettre de lancer les programmes que tu veux en 10 minutes sur toutes les plateformes, mais tu vas pouvoir faire tout un tas de choses potentiellement intéressantes pour un attaquant, au niveau de la confidentialité, de l'intégrité ou juste de la disponibilité de sous-systèmes.
Dans la modélisation des menaces, il y a très peu de cas pour lesquels un fabriquant de carte mère de PC classique et encore moins un utilisateur souhaiterait être résistant dans certains domaines face à un accès direct à la carte mère. Ça peut exister, mais dans des cas spéciaux, pas vraiment dans le cas général. Dans le cas général on peut considérer que la personne qui accède à la carte mère possède le pc (soit qu'elle le possède au sens légal, soit qu'elle le "own")
Dans une modélisation des menaces qui prend ce fait en compte, il est totalement possible de concevoir, sans surcoût exorbitant, des mécanismes de boot sécurisés qui ne se résument pas simplement à la construction de prisons dorées sous iMarque, sous l'empire des Fenêtres, ni sous big brotheria Googlesque. Il suffit de permettre de rendre accessible par un jumper une zone normalement read-only, de manière à ce que l'utilisateur puisse installer ses propres clefs racines si l'envie lui prend.
On n'a donc pas dans l'absolu à subir le prix démesuré de la perte de la possibilité par l'utilisateur d'installer ce qu'il désire dès que le système dispose d'un boot sécurisé.
Malheureusement en pratique certaines boites ont tout intérêt à ce que les boots sécurisés n'incluent pas cette possibilité (et je parle d'informatique généraliste, pas de truc dédiée multimédia ni de console de jeux-vidéos). Toutes leurs docs de référence et de conformité seront orientés pour que les OEM fassent des cartes avec impossibilité de maj les clefs racines (rien que la simple omission serait efficace en la matière, et ne parlons pas d'une rédaction astucieuse par un type ayant explicitement ça en tête) et même de plus de préférence avec impossibilité de désactiver le boot "sécurisé", que l'on devrait alors plutôt renommer en boot de mise sous-tutelle (si vous avez une expression encore plus stylée en tête, merci de la proposer en réponse à ce commentaire). Lesdites boites se défendront d'avoir cette démarche et répondront à toute critique en disant qu'ils n'interdisent pas aux OEM d'implémenter aussi un autre mécanisme autorisant le démarrage d'OS "alternatifs" (si possible en sous-entendant au passage qu'ils ne pourront pas profiter de boot sécu ou alors dans des conditions faisant passer Windows pour un système ouvert)
La sécurité et l'indépendance vont de pair. La capacité souveraine des possesseurs d'infrastructure numérique de régler ou faire régler par la personne de leur choix les problèmes dans les logiciels qu'ils utilisent sans pour autant être soumis au bon vouloir absolu de fournisseurs imposés (cela peut éventuellement nécessiter des moyens importants) est primordiale si l'on souhaite avoir de réelles capacités de défense, et il est tout autant primordial que cela ne nécessite pas la désactivation d'autres aspects de sécurité. Cela peut valoir pour les individus, pour les organisations, pour les états, pour tout le monde. Dans la guerre contre les ordinateurs universels qui se prépare, il est important d'exiger que les fonctionnalités du matériel ne soient pas réservées aux seuls empires sans âmes rêvant de dupliquer des modèles commerciaux de vendeurs de gadgets de luxe.