Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Secure Boot : Microsoft a laissé une porte dérobée ouverte

CQFD

Secure Boot : Microsoft a laissé une porte dérobée ouverte

Le 11 août 2016 à 12h00

Mauvaise semaine pour Microsoft, qui fait face à un sérieux problème : la fuite de clés permettant d’ouvrir Secure Boot sur n’importe quelle machine. Bien que la méthode ne puisse pas être exploitée pour infiltrer un malware, le cas – d’école – rappelle à quel point les portes dérobées sont une mauvaise idée.

Secure Boot est un mécanisme prévu essentiellement pour bloquer toute tentative d’insertion d’un élément nocif dans la chaine du démarrage. Il s’agit d’une fonctionnalité de la norme UEFI, impliquant des éléments signés. L’une des conséquences est qu’une machine l’exploitant complètement ne peut démarrer qu’un système signé avec une clé validée par Microsoft. En clair, outre Windows, il est complexe d’installer autre chose, même s'il peut être mal implémenté, au risque donc d'être inutile.

Secure Boot fonctionne avec des clés ainsi qu’un lot de règles. Ces dernières définissent la manière dont les mécanismes se déroulent, les éléments à ajouter, ceux à ne pas prendre en compte et ainsi de suite. Or, pour que les OEM notamment puissent tester Secure Boot sur leur machine, Microsoft a mis en place des « golden keys », en fait une règle bien spécifique qui bloque le contrôle des signatures par le gestionnaire de démarrage de Windows.

Oups

Normalement, cette règle ne devrait être fournie qu’à ceux qui en ont besoin, après avoir dument montré patte blanche. Mais Microsoft a fait pour ainsi dire une petite boulette : cette règle « mode debug » est présente dans toutes les machines. Elle ne devrait évidemment pas, mais la conséquence est bien là.

En théorie, n’importe qui peut donc activer cette règle, et les scripts ont déjà fleuri en plusieurs endroits. La découverte a été faite par deux chercheurs, utilisant les pseudos MY123 and Slipstream, qui relatent l’intégralité de leurs trouvailles sur un site spécialement créé pour l’occasion (il faut attendre un peu devant l’animation avant que le texte n’apparaisse).

Il ne semble pas possible pour l’instant d’insérer le moindre malware dans la chaine du démarrage sans que l’utilisateur ne s’en aperçoive. Par contre, la désactivation du contrôle de boot permet à un appareil de démarrer sur n’importe quel système d’exploitation. Il peut s’agir de PC, de tablettes ou de smartphones, les architectures x86 et ARM étant supportées. Certains voient déjà de quoi redonner une nouvelle jeunesse à des Surface RT laissées à l’abandon. Ou pourquoi pas installer Android sur des Lumia.

Un problème qui ne pourra peut-être pas être complètement résolu

Pour Microsoft, c’est par contre un sérieux problème, une faute d’inattention si grave qu’on se demande comment elle a pu passer au travers des mailles du filet. Les chercheurs ont averti l’éditeur de la situation en mars dernier. Dans un premier temps, Microsoft n’a pas considéré sérieusement la faille. Mais en avril, changement de ton, les chercheurs récupérant même au passage une prime dans le cadre du programme maison de chasse aux bugs.

Un premier correctif a été diffusé en juillet. Estampillé MS16-094, il met en place une liste de révocation vérifiée par le gestionnaire de démarrage de Windows. Mais cette solution comporte là aussi une faille « bête » : la liste est consultée après le chargement des règles. Si la règle incriminée a déjà été activée, le correctif n’y changera rien. Dans le cas contraire, il est effectif, d’autant que l’outil d’activation des règles a lui aussi été mis à jour.

Les chercheurs ont indiqué que de nouveaux scripts seraient proposés pour contourner le patch MS16-094. Microsoft prévoit de toute façon déjà un troisième correctif le mois prochain, alors qu’un deuxième a été distribué mardi soir pour le Patch Tuesday. MY123 and Slipstream estiment cependant qu’il ne sera pas possible de refermer complètement la brèche. L’entreprise vient d’apporter, malgré elle, un argument de poids dans le débat très vif au sujet de la sécurité et des portes dérobées.

Les portes dérobées sécurisées n'existent pas

Difficile en effet de ne pas penser aux questions posées par le chiffrement, et plus particulièrement son expansion à travers un nombre croissant de services. Un phénomène dû en partie aux révélations de Snowden, qui ont montré l’étendue des services de renseignements, particulièrement aux États-Unis. Or, devant cette croissance, les forces de l’ordre, le FBI et autres émanations gouvernementales (quand ce ne sont pas les gouvernements eux-mêmes) cherchent des solutions, dont la plus souvent entendue est la mise en place de portées dérobées sécurisées.

Comme indiqué à de nombreuses reprises, il n’existe rien de tel. Une porte ne peut être à la fois dérobée et sécurisée, car il existera toujours le risque que la clé échappe aux propriétaires ou qu’elle soit trouvée d’une autre manière. L’erreur de Microsoft prouve – s’il y en avait encore besoin – que le danger est réel. Car si l’erreur est surtout ennuyeuse ici pour l’entreprise, elle pourrait tout aussi bien avoir lieu avec un algorithme de chiffrement conçu de cette manière. Il n’est pas exclu d’ailleurs que le FBI et d’autres agences profitent de cette erreur.

Commentaires (108)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Enorme <img data-src=" />



mais en pratique c’est jamais actif à 100% non ? toujours pu installer un autre OS non Microsoft sans problème (autre que faire gaffe à ses partitions et secteur de démarrage) <img data-src=" />

votre avatar

En fait c’est surtout sur les Surface RT et autres appareils du genre que le Secure Boot est activé, et empêche l’installation de tout autre OS.

votre avatar

Le truc que je désactive à chaque coup..

votre avatar

Je ne comprends pas trop la corrélation entre le boot sur un OS et une porte dérobée ?

Ça veut dire qu’un boot Windows implique des échanges ?

votre avatar

J’ai vu plusieurs petits PC (hybrides ou PC de taille similaire) sur lesquels ça empêchait d’installer Ubuntu. Et l’article parle aussi des smartphones Lumia pour lesquels il y a de grandes chances que ce soit actif à 100%.

votre avatar

L’appareil accepte de booter sur l’OS proposé seulement si il a une clé windows. La porte dérober permet de faire booter l’appareil sur n’importe quel OS :-)

votre avatar

Si ça peut effectivement me refaire sortir ma Surface RT, ça serait très intéressant.

votre avatar

Comment ? Qu’est-ce que j’apprends ? Les backdoors sont des failles de sécurité ?

Je tombe des nues… <img data-src=" />

votre avatar







Mathayus a écrit :



Si ça peut effectivement me refaire sortir ma Surface RT, ça serait très intéressant.





Sinon, pour caler une table bancale….&nbsp;


votre avatar







Ricard a écrit :



Sinon, pour caler une table bancale….&nbsp;





Je m’en sers surtout actuellement en planche à découper :P


votre avatar

<img data-src=" />

votre avatar

99.99% des malwares et des adwares s’installent sur le compte de l’utilisateur courant limité et le vivent très bien. Microsoft a toujours assuré la rétro-compatibilité avec leurs conneries 😃



Pourquoi chercher plus compliqué ? <img data-src=" />

votre avatar

j’ai lu un commentaire ici, il n’y a pas si longtemps, sur quelqu’un qui avait plus confiance en Microsoft que Google et Apple pour la sécurité.







<img data-src=" />

votre avatar

Ben Google et Apple aussi ont des failles dans leurs systèmes.

Si tu abandonnes un éditeur à la première bourde de sécurité, t’as pas fini de changer d’OS.

votre avatar







wannted a écrit :



j’ai lu un commentaire ici, il n’y a pas si longtemps, sur quelqu’un qui avait plus confiance en Microsoft que Google et Apple pour la sécurité.







<img data-src=" />



C’est sûr qu’ils sont au top niveau sécu <img data-src=" /> <img data-src=" />


votre avatar

Je comprends pas comment la signature a pu être réservée au seul Microsoft (et on voit où ça nous a mené).

Tous les systèmes vendus en Europe devraient intégrer un certificat qui permettrait de signer les bootloaders après audit.&nbsp;

votre avatar

Il faut en effet bien pouvoir tester: Mon petit doigt me dit que ces bypass aux modes de boot sécurisés doivent exister a peu près partout, plus ou moins bien planqué!

C’est un concept qui ne sert qu’a priver l’utilisateur du droit de faire ce qu’il veut de ce qu’il achète, pas à sécuriser sa machine. Surtout sur un élément pas vraiment facile à exploiter de manière fiable.

votre avatar







Maicka a écrit :



Le truc que je désactive à chaque coup..







Si le gentil constructeur t’en laisse la possibilité. Ce qui n’est pas toujours le cas…


votre avatar

Si ça ne permet pas d’infiltrer un malware mais permet de booter sur l’OS que l’on veut c’est plutôt une bonne chose non ? Sauf peut-être pour MS mais qu’est ce qu’on s’en fout ?

votre avatar







v1nce a écrit :



Je comprends pas comment la signature a pu être réservée au seul Microsoft (et on voit où ça nous a mené).

Tous les systèmes vendus en Europe devraient intégrer un certificat qui permettrait de signer les bootloaders après audit.





Et les systèmes qui ne sont pas “vendus”, tu en fais quoi ?



Je ne vois pas ce que ça change, entre payer Microsoft et payer une entreprise de certification.


votre avatar
votre avatar







Fishkill a écrit :



L’appareil accepte de booter sur l’OS proposé seulement si il a une clé windows. La porte dérober permet de faire booter l’appareil sur n’importe quel OS :-)





Ça veut dire que j’achète un Dell (par exemple) j’achète l’OS qui est prévu avec ? Bon nombre de PC sont sans OS… J’ai du mal à cerner les limites.


votre avatar

Dans l’article original, les auteurs interpellent directement le FBI sur son idée d’intégrer des portes dérobées. Dommage que NXInpact n’est pas souligné ce point!

votre avatar

L’UEFI permet surtout à microsoft de réécrire l’ordre de démarrage en mémoire à son avantage. Sur plusieurs modèles, un simple passage dans le BIOS et hop : votre grub disparaît ! Il faut repasser par efibootmgr pour arrêter les conneries. Certains copains fabricants continuent ainsi de lécher les bottes de microsoft à tout va, et ce superbe abus de position dominante n’est pas un hasard de plus.

Concrètement, le SB, n’ajoute aucune sécurité réelle, et est surtout là pour emmerder les libristes. N’oublions pas que la partition UEFI est en FAT, et que c’est microsoft qui distribue les clés, et a ansi réussi à se rendre indispensable de fait. Encore un abus de plus pour une société qui n’a plus rien dans les boyaux. Il est heureux que les fabricants aient compris qu’il valait mieux pour eux laisser l’option de désactivation de cette merde.

Plus globalement, le SB n’ajoute finalement rien à la sécurité bancale de windows. Non content d’utiliser ses mises à jour en cheval de troie, en les rendant encore obligatoires et non désactivables sur les versions grand public, on ne compte plus les plantages de machines dues à ces même mises à jour, ce qui prouve bien que l’éditeur ne maîtrise plus son propre produit. On a désormais plus de problèmes en laissant les mises à jour activées qu’en bridant ces mises à jour. Et là je parle de versions pro, qui constituent malheureusement l’énorme majorité des windows en PME/PMI. Je n’ose même pas imaginer le bordel subit côté particuliers !

Finalement, la seule bonne nouvelle de cette news, c’est qu’on pourra peut être récupérer du matériel bridé avec de l’OS GNU/Linux, si certains ont envie de s’amuser. Pour ma part, cela prouve surtout que la NSA a encore bien travaillé, et que le “fait moi confiance” de nos amis GAFAM est la meilleure méthode pour se faire plumer.

Pour le reste, la dernière Ubuntu 16.04 fonctionne nickel. Idem côté Debian 8. Difficile de demander plus qu’un ordinateur qui marche, sans se prendre la tête. Il est surtout surprenant, quand on compare les deux OS, qu’il y ait encore des gens sous windows…

votre avatar







KissFC a écrit :



Si tu prend tianocore de base, le module secure boot se résume a intégration de certifs x509, une fonction sha256 pour le hash, db et dbx. Microsoft demande une interface compilée avec leurs compilo UEFI maison avec un flag mft sur le module, et que le binaire soit signé via HSM. Y’a pas de standardisation. CoreBoot a techniquement un moteur de gestion de signatures qui permet d’avoir un secureboot fonctionnel mais pas de clés MS intégrées : c’est pas standard encore une fois.

Donc les fabricants de CM/OEM/Intégrateurs font se qui va leurs rapporter des brouzoufs : certif microsoft même si c’est pas standard et basta.







C’est bien là le problème il me semble : que l’implémentation ne soit pas standardisée.









KissFC a écrit :



Le soucis, c’est que si les utilisateurs ne poussent pas a demander un standard avec une gestion centralisée documentée, MS se bougera pas et les fabricants de CM non plus, la réponse que les utilisateurs sortent c’est “je désactive SB” ou “je passe en legacy + CSM” (se qui est encore pire).







Les fabricants conçoivent, l’utilisateur utilise.



Si le design est mal fichu, il ne faut pas s’étonner que l’utilisateur utilise des bypass. L’utilisateur veut juste aller au plus simple ou au plus rapide pour atteindre son but.



Design VS User Experience



Alors, les designers râlent après les utilisateurs, les utilisateurs râlent après les designers… Cela signifie une chose : le design (ou son implémentation) ne répondent pas correctement aux besoins des utilisateurs.



Perso en tant qu’utilisateur, je veux juste utiliser ma machine de la façon la plus simple qui soit. Si pour moi c’est plus simple de désactiver Secure Boot pour installer la distro GNU/Linux que je veux, alors soit, je vais désactiver Secure Boot, c’est tout.









KissFC a écrit :



Moralité, c’est pas après microsoft qu’il faut gueulé, mais après asus, gigabyte, whatever, de supporter le soft.







C’est bien noté. En tant qu’utilisateur, voilà ce que je demande : que tout ce beau monde travaille ensemble, élabore des standards, les implémente comme il faut, et fasse en sorte que moi (utilisateur) je puisse utiliser ma machine simplement.


votre avatar







hansi a écrit :



L’UEFI permet surtout à microsoft de réécrire l’ordre de démarrage en mémoire à son avantage. Sur plusieurs modèles, un simple passage dans le BIOS et hop : votre grub disparaît ! Il faut repasser par efibootmgr pour arrêter les conneries.





Oui, c’est même un avantage de l’UEFI. Avec BIOS, il fallait réinstaller le MBR, avec UEFI il suffit de reconfigurer l’ordre de démarrage, ça prend environ cinq secondes. La bonne solution serait évidemment que Windows demande l’avis de l’utilisateur avant de modifier la configuration du boot, mais il ne faut pas rêver…


votre avatar







Quiproquo a écrit :



Oui, c’est même un avantage de l’UEFI. Avec BIOS, il fallait réinstaller le MBR, avec UEFI il suffit de reconfigurer l’ordre de démarrage, ça prend environ cinq secondes. La bonne solution serait évidemment que Windows demande l’avis de l’utilisateur avant de modifier la configuration du boot, mais il ne faut pas rêver…







C’est vrai que Windows ne demande jamais l’avis de l’utilisateur quand il s’agit de réécrire le MBR, ni a forciori de reconfigurer l’UEFI. Microsoft considère sans doute que Windows est le seul OS digne d’être installé sur tout PC UEFI. Les autres OS sont une nuisance, les désactiver au boot rend forcément service à l’utilisateur.


votre avatar







KissFC a écrit :



Je te laisse voir les spec d’EFI sur Itanium, d’EFI sur matos Apple. Du blindage demandé par IBM sur leurs serveurs. Et les demandes de RedHat concernant l’UEFI, d’ailleurs, Shim, c’est pas un hasard si ça provient de RedHat (il était dans les cartons depuis un bout de temps, puisqu’ils ont bossés a l’intégration de x509 non seulement dans le kernel linux mais aussi dans l’EFI, c’est AUSSI pour ça que Linus l’a mauvaise concernant le secure boot.)

Le problème n’est encore une fois, pas la technologie en elle même, ni l’organisme certificateur. &nbsp;



[Autre post]

&nbsp;

Mais SB a été poussé par les fabricants de smartphone, RedHat, Apple, IBM, pas microsoft.

DEAL

WITH&nbsp;

IT

Au lieu de raconter de la merde.



&nbsp;

Merci de confirmer ce que je disais en indiquant que les noms que tu citais visaient les professionnels. Que je sache, Itanium n’est pas pour le grand public. IBM ne fabrique même plus d’ordinateurs classiques, etc.



Que l’on trouve Secure Boot sur toutes les cartes mère même grand public ne pouvait être le fruit que d’une seule société avec le poids requis pour imposer cela, et c’était Microsoft. Tu peux toujours dénoncer ceux qui crient au “complotisme”, en attendant c’est comme ça, point.


votre avatar

Je ne comprend pas la dernière phrase.

La porte dérobé a toujours existé, mais elle a été mis en lumière par 2 chercheurs.

Le FBI pouvait très bien être au courant et utiliser abondamment cette porte bien avant que des chercheurs la publie.

&nbsp;

&nbsp;

votre avatar

Une backdoor normalement destinée à un environnement de debug, ce n’est pas vraiment une backdoor. Le problème est que ça s’est retrouvé dans la nature, pas qu’ils aient créé cette backdoor dès le départ.

votre avatar







CR_B7 a écrit :



Je ne comprend pas la dernière phrase.

La porte dérobé a toujours existé, mais elle a été mis en lumière par 2 chercheurs.

Le FBI pouvait très bien être au courant et utiliser abondamment cette porte bien avant que des chercheurs la publie.

&nbsp;

&nbsp;





mais c’est très certainement la cas, Microsoft à du communiquer au FBI &nbsp;et cie sa backdoor. Moi je constate juste que le FBI ne se plaint jamais des produits Microsoft, mais des produits Apple c’est une tout autre histoire..&nbsp;


votre avatar







ErGo_404 a écrit :



Une backdoor normalement destinée à un environnement de debug, ce n’est pas vraiment une backdoor. Le problème est que ça s’est retrouvé dans la nature, pas qu’ils aient créé cette backdoor dès le départ.





&nbsp;Le mieux pour éviter ce genre de problème c’est de ne pas avoir ce genre de système avec “clé maître” Et puis cette “backdoor d’environnement de debug” évidement que les autorités américaine l’ont déjà en leur possesion..


votre avatar







CR_B7 a écrit :



Je ne comprend pas la dernière phrase.

La porte dérobé a toujours existé, mais elle a été mis en lumière par 2 chercheurs.

Le FBI pouvait très bien être au courant et utiliser abondamment cette porte bien avant que des chercheurs la publie.







Hum… ca dépend ce que tu appelles “porte dérobée”.



SI tu parles du fonctionnement normal de BootMgr (= chargement et exécution de “policies” spécifiques à une machine et signées par Ms), alors oui ca a toujours existé. Et le FBI peut très bien demander a Ms de lui fabriquer des “policies” pour une machine particulière (le FBI envoie le DeviceId et Ms renvoie une “policies” spécifique)



Si tu parles de la faille découverte par les deux chercheurs, elle existe “seulement” depuis Windows 10 v1607. En gros, la faille c’est que la version v1607 de BootMgr charge certaines “policies” sans vérifier le DeviceID ni la signature de Ms (<img data-src=" />). Donc, en installant cette version de BootMgr sur un PC et en fabriquant une “Policies” particulière, on peut désactiver SecureBoot.


votre avatar

En gros le fbi n’est plus obliger d’agir machine par machine, mais il peut avoir l’anneau pour les gouverner tous … :)

votre avatar

C’est tellement gros qu’on se demande si c’était pas voulu…

votre avatar

PROJECT SAURON c’est la news d’à coté. <img data-src=" />

votre avatar

Exactement, car l’étape suivante après l’avoir rendu “optionnel” (et oublié sciemment de mentionner la possibilité de mettre ses propres clés) c’est de le rendre “non désactivable”.



Bref cela ne “Sécurise” qu’une chose : le modèle économique basé sur le racket de M$ !..

votre avatar

Cette backdoor permet de booter n’importe quoi.

Tu bootes sur Kon Boot et tu as le système tout entier, il supporte Windows 10.



Tu vois l’enjeu ? C’est énorme.

votre avatar

J’ai cru lire que tu étais tombé tout nu !



<img data-src=" />

votre avatar

On est d’accord que pour effectuer une telle manipulation et un tel reboot sur un autre OS, il faut que les conditions suivantes soient requises :





  • Accès à la machine en question (Physiquement)

  • Que la machine n’héberge pas de service permettant de remarquer l’extinction

  • Que l’utilisateur ne cherche pas à se servir de sa machine durant toute la période d’exploitation de son système.



    Parce qu’une faille de la mort qui tue qui fait que ton pc reboote sur un autre OS que le tien, c’est limite niveau discrétion.&nbsp;Donc je vois pas trop le danger en fait (Outre l’aspect commercial qui permet de booter des autres OS sur des plateformes pour laquelle Microsoft a signé le deal licence moins chères contre pas de changement d’OS).

votre avatar







vampire7 a écrit :



J’y verrais un problème si je pensais que les entreprises de certification sont incorruptibles et indépendantes, ce qui n’est pas le cas.







Ce n’est pas une fatalité. Quand il s’agit d’un consortium de plusieurs entreprises, alors il n’y a pas qu’une seule entreprise qui fait la pluie et le beau temps, elles fixent les règles ensemble et chacune doit ensuite les respecter.



C’est typiquement ce qui aurait dû se passer pour UEFI et Secure Boot : un consortium impliquant les constructeurs, les éditeurs d’OS etc., s’ils avaient bien fait les choses.


votre avatar

Du coup hack de la Xbox One soon non ?

votre avatar

voila qui ressemble à une signature ;) :



075eea060589548ba060b2feed10da3c20c7fe9b17cd026b94e8a683b8115238

07e6c6a858646fb1efc67903fe28b116011f2367fe92e6be2b36999eff39d09e

09df5f4e511208ec78b96d12d08125fdb603868de39f6f72927852599b659c26

0bbb4392daac7ab89b30a4ac657531b97bfaab04f90b0dafe5f9b6eb90a06374

0c189339762df336ab3dd006a463df715a39cfb0f492465c600e6c6bd7bd898c

0d0dbeca6f29eca06f331a7d72e4884b12097fb348983a2a14a0d73f4f10140f

0dc9f3fb99962148c3ca833632758d3ed4fc8d0b0007b95b31e6528f2acd5bfc

106faceacfecfd4e303b74f480a08098e2d0802b936f8ec774ce21f31686689c

174e3a0b5b43c6a607bbd3404f05341e3dcf396267ce94f8b50e2e23a9da920c

18333429ff0562ed9f97033e1148dceee52dbe2e496d5410b5cfd6c864d2d10f

2b99cf26422e92fe365fbf4bc30d27086c9ee14b7a6fff44fb2f6b9001699939

2bbf2ca7b8f1d91f27ee52b6fb2a5dd049b85a2b9b529c5d6662068104b055f8

2c73d93325ba6dcbe589d4a4c63c5b935559ef92fbf050ed50c4e2085206f17d

2e70916786a6f773511fa7181fab0f1d70b557c6322ea923b2a8d3b92b51af7d

306628fa5477305728ba4a467de7d0387a54f569d3769fce5e75ec89d28d1593

3608edbaf5ad0f41a414a1777abf2faf5e670334675ec3995e6935829e0caad2

3841d221368d1583d75c0a02e62160394d6c4e0a6760b6f607b90362bc855b02

3fce9b9fdf3ef09d5452b0f95ee481c2b7f06d743a737971558e70136ace3e73

4397daca839e7f63077cb50c92df43bc2d2fb2a8f59f26fc7a0e4bd4d9751692

47cc086127e2069a86e03a6bef2cd410f8c55a6d6bdb362168c31b2ce32a5adf

518831fe7382b514d03e15c621228b8ab65479bd0cbfa3c5c1d0f48d9c306135

5ae949ea8855eb93e439dbc65bda2e42852c2fdf6789fa146736e3c3410f2b5c

6b1d138078e4418aa68deb7bb35e066092cf479eeb8ce4cd12e7d072ccb42f66

6c8854478dd559e29351b826c06cb8bfef2b94ad3538358772d193f82ed1ca11

6f1428ff71c9db0ed5af1f2e7bbfcbab647cc265ddf5b293cdb626f50a3a785e

71f2906fd222497e54a34662ab2497fcc81020770ff51368e9e3d9bfcbfd6375

726b3eb654046a30f3f83d9b96ce03f670e9a806d1708a0371e62dc49d2c23c1

72e0bd1867cf5d9d56ab158adf3bddbc82bf32a8d8aa1d8c5e2f6df29428d6d8

7827af99362cfaf0717dade4b1bfe0438ad171c15addc248b75bf8caa44bb2c5

81a8b965bb84d3876b9429a95481cc955318cfaa1412d808c8a33bfd33fff0e4

82db3bceb4f60843ce9d97c3d187cd9b5941cd3de8100e586f2bda5637575f67

895a9785f617ca1d7ed44fc1a1470b71f3f1223862d9ff9dcc3ae2df92163daf

8ad64859f195b5f58dafaa940b6a6167acd67a886e8f469364177221c55945b9

8bf434b49e00ccf71502a2cd900865cb01ec3b3da03c35be505fdf7bd563f521

8d8ea289cfe70a1c07ab7365cb28ee51edd33cf2506de888fbadd60ebf80481c

9998d363c491be16bd74ba10b94d9291001611736fdca643a36664bc0f315a42

9e4a69173161682e55fde8fef560eb88ec1ffedcaf04001f66c0caf707b2b734

a6b5151f3655d3a2af0d472759796be4a4200e5495a7d869754c4848857408a7

a7f32f508d4eb0fead9a087ef94ed1ba0aec5de6f7ef6ff0a62b93bedf5d458d

ad6826e1946d26d3eaf3685c88d97d85de3b4dcb3d0ee2ae81c70560d13c5720

aeebae3151271273ed95aa2e671139ed31a98567303a332298f83709a9d55aa1

afe2030afb7d2cda13f9fa333a02e34f6751afec11b010dbcd441fdf4c4002b3

b54f1ee636631fad68058d3b0937031ac1b90ccb17062a391cca68afdbe40d55

b8f078d983a24ac433216393883514cd932c33af18e7dd70884c8235f4275736

b97a0889059c035ff1d54b6db53b11b9766668d9f955247c028b2837d7a04cd9

bc87a668e81966489cb508ee805183c19e6acd24cf17799ca062d2e384da0ea7

c409bdac4775add8db92aa22b5b718fb8c94a1462c1fe9a416b95d8a3388c2fc

c617c1a8b1ee2a811c28b5a81b4c83d7c98b5b0c27281d610207ebe692c2967f

c90f336617b8e7f983975413c997f10b73eb267fd8a10cb9e3bdbfc667abdb8b

cb6b858b40d3a098765815b592c1514a49604fafd60819da88d7a76e9778fef7

ce3bfabe59d67ce8ac8dfd4a16f7c43ef9c224513fbc655957d735fa29f540ce

d8cbeb9735f5672b367e4f96cdc74969615d17074ae96c724d42ce0216f8f3fa

e92c22eb3b5642d65c1ec2caf247d2594738eebb7fb3841a44956f59e2b0d1fa

fddd6e3d29ea84c7743dad4a1bdbc700b5fec1b391f932409086acc71dd6dbd8

fe63a84f782cc9d3fcf2ccf9fc11fbd03760878758d26285ed12669bdc6e6d01

fecfb232d12e994b6d485d2c7167728aa5525984ad5ca61e7516221f079a1436

ca171d614a8d7e121c93948cd0fe55d39981f9d11aa96e03450a415227c2c65b

55b99b0de53dbcfe485aa9c737cf3fb616ef3d91fab599aa7cab19eda763b5ba

77dd190fa30d88ff5e3b011a0ae61e6209780c130b535ecb87e6f0888a0b6b2f

c83cb13922ad99f560744675dd37cc94dcad5a1fcba6472fee341171d939e884

3b0287533e0cc3d0ec1aa823cbf0a941aad8721579d1c499802dd1c3a636b8a9

939aeef4f5fa51e23340c3f2e49048ce8872526afdf752c3a7f3a3f2bc9f6049

64575bd912789a2e14ad56f6341f52af6bf80cf94400785975e9f04e2d64d745

45c7c8ae750acfbb48fc37527d6412dd644daed8913ccd8a24c94d856967df8e

votre avatar

C’est le cas, pourtant.

votre avatar







tazvld a écrit :



Si c’est un PC x86/x64 ce devrait normalement être possible de désactiver le secure boot. Et quand bien même il ne serait pas désactivable, Ubuntu a normalement une clé valide.



&nbsp;

&nbsp;Pour ma part, sur un UEFI Acer, j’ai une fois cru que secure boot ne serait pas désactivable: L’option apparaissait grisée. Je m’apprêtais à renvoyer au vendeur ce laptop pas conforme quand j’ai vu que mettre un MDP permettait de débloquer l’option (un truc grisé incite à chercher un peu, option non présente je pense que ca aurait été retour direct).



Ce que j’ai trouvé un peu idiot comme précaution: Pas grand monde ne mettant un mdp au BIOS/UEFI, cela signifie en pratique celui qui a accès physique à la machine peut débloquer le 1er le secure boot et empêcher l’utilisateur légitime de le remettre!



Mais bon, peut-être n’est-ce pas un cas isolé: On croit que c’est pas là… et en fait si? Penser à essayer de mettre un mdp!


votre avatar

Shim a une clé valide. &nbsp;Tu peut installer une MOK sur Shim. Tu as donc des clés valides.

Pour les tablettes et autres : suffit de passer en mode debug hard (qui lui est obligatoire ne serait-ce que pour initier les puces) qui te permet … De passer outre secure boot et d’installer n’importe quoi dessus.

J’ai une surface pro avec mes propres bd/bdx/PK et KEK, en dual boot linux/windows et j’ai juste aucuns soucis.

votre avatar

L’option de désactiver le secure boot peut bien ne plus être présente : c’est un faux problème, CF au dessus, tu peut installer tes propres clés.

votre avatar







stratic a écrit :



Si le gentil constructeur t’en laisse la possibilité. Ce qui n’est pas toujours le cas…







un appareil qui dispose d’un OS qiu me convient pas, je le change.

Si je peux pas, je le revends, je le garde pas en ma possession


votre avatar







v1nce a écrit :



Je comprends pas comment la signature a pu être réservée au seul Microsoft (et on voit où ça nous a mené).

Tous les systèmes vendus en Europe devraient intégrer un certificat qui permettrait de signer les bootloaders après audit.







Non, rien ne devrait se baser sur des certificats qui sont révoqués des années plus tard, sans proposer de maj derriere.


votre avatar

Bon, je le redis parce que visiblement, y’en a qui sont dur de la feuille : la question des certificats est un faux problème.

Vous pouvez être votre propre autorité de certification. CF le lien posté au dessus. La question de microsoft seul et unique signataire est donc nulle. Qu’ils soient la seule autorité reconnue au niveau industriel est un fait, encore que c’est VeriSign qui signe les certificats pour microsoft. Qu’il ne soit pas possible de signer les certificats autrement est faux.

Si les certificats sont révoqués : pas de soucis, signe tes propres certificats épicétou.



Edit : le problème ici n’est pas que seul microsoft puisse signer, mais que windows laisse une possibilité de booter en mode debug, et que des golden keys sont dans la nature. (édition BCD et certificats propres permettent de virer totalement la faille.)

votre avatar







KissFC a écrit :



L’option de désactiver le secure boot peut bien ne plus être présente : c’est un faux problème, CF au dessus, tu peut installer tes propres clés.






 Si, c'est un vrai problème car comme la majorité des utilisateurs, j'ai hélas raté mon diplôme en cryptosécurité, c'est ballot mais c'est comme ça. Et donc je ne vois pas du tout comment procéder : mettre des clés ? d'accord, quelles clés ? Je dois les créer ? Si oui, je procède comment avant de les injecter dans le BIOS ? Si non, je les récupère où ? etc. Et après une fois qu'on a les infos comme dans ton lien, c'est "Est-ce que ça va être contraignant ? Est-ce que ça va demander de la maintenance ? Est-ce que je vais vraiment y gagner par rapport aux efforts dépensés dessus ?".     







 Non là je me mets en mode utilisateur qui ne veut pas se faire chier avec une feature qui lui est inutile et lui complique considérablement son libre choix d'OS : Je veux une option visible le coupant d'un seul coup, point.

votre avatar

D’ailleurs, sur ma carte mère (une MSI 990FXA Gaming), par défaut, les clefs de Microsoft ne sont pas chargées. Il propose d’abord de mettre les siennes.



Du coup, il m’a fallut un peu de temps pour comprendre qu’il fallait faire “charger les valeurs par défaut” pour qu’il importe les clefs de Microsoft et que je ne me prenne pas la tête à les créer moi-même !

votre avatar







TheKillerOfComputer a écrit :



Si, c’est un vrai problème car comme la majorité des utilisateurs, j’ai hélas raté mon diplôme en cryptosécurité, c’est ballot mais c’est comme ça. Et donc je ne vois pas du tout comment procéder : mettre des clés ? d’accord, quelles clés ? Je dois les créer ? Si oui, je procède comment avant de les injecter dans le BIOS ? Si non, je les récupère où ? etc. Et après une fois qu’on a les infos comme dans ton lien, c’est “Est-ce que ça va être contraignant ? Est-ce que ça va demander de la maintenance ? Est-ce que je vais vraiment y gagner par rapport aux efforts dépensés dessus ?”. 




 Non là je me mets en mode utilisateur qui ne veut pas se faire chier avec une feature qui lui est inutile et lui complique considérablement son libre choix d'OS : Je veux une option visible le coupant d'un seul coup, point.




Je voulais écrire un message du même genre. Tu m’as devandé. Ca m’évite de le faire moi-même… <img data-src=" />


votre avatar

http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html&nbsp;Tout est expliqué, ici.

&nbsp;Tout est expliqué dans l’implémentation de secureboot sur le site d’intel. Tout est expliqué dans le compendium pour l’EDK, et depuis que l’EFI existe sur plateforme itanium, et qu’apple ont commencés a installer les premiers éléments de sécurisation du boot.



&nbsp;Et c’est pas de la crypto mais de l’admin sys.

&nbsp;Et c’est de la très mauvaise fois que de basher microsoft sur ce point : ils sont unique certificateurs par défaut parce que personne d’autre ne veux le faire, les industriels demandant des garanties juste impressionnantes.

&nbsp;De plus, la certification et la révocation, sont sur plateforme microsoft, juste transparente. C’est pas comme si l’OS avait accès a la partie dbx/KEK/KEXt de la nvram stockant les infos UEFI/Boot/BCD.

&nbsp;Et d’ailleurs, de ce point de vue, linux est une faille de sécurité a lui tout seul : lui y accède en dur via le shell.



&nbsp;Et là, entre nous, si tu&nbsp;t’intéresse&nbsp;un minimum au sujet, tu verra que l’utilisateur lambda tel que tu le décris ne pourra être impacté par ce genre de failles : faut un accès physique a la machine. Ca peut permettre de véroler un kiosk sous windows et de le démarrer en mode “admin”, mais dans les faits avant de pouvoir installer un malware qui ira te véroler l’OS, voir un OS vérolé tout court, y’a un gouffre.

&nbsp;Et non, ça ne sera jamais simple, car c’est une fonction qui peut bricker une carte mère. (modifier les db/PK demande d’aller directement éditer les bases dans les oproms contenant l’UEFI, et donc d’écrire en mode réel, et donc … de ne plus être en mesure de booter, du tout.).



&nbsp;Seule exception, les périph ARM qui ont leurs mécanismes par design sur une partoche spécifique du stockage de masse. Seul le POST est réalisé en hard (et intégré au SoC).

votre avatar

Tu ne veux pas mettre quelques sauts de lignes ? <img data-src=" />

votre avatar

Y’en avait, ils ont sauté. Je tente l’edit :O



Edit : ça me fait penser qu’il y a des goldens arm dans la nature depuis 2010 qui permettent de booter sur des chip samsung et snapdragon.

Quand c’est pour du jailbreak, on en parle positivement, mais quand c’est sur x86, oulalala.&nbsp;

votre avatar







KissFC a écrit :



http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html&nbsp;Tout est expliqué, ici.

&nbsp;Tout est expliqué dans l’implémentation de secureboot sur le site d’intel. Tout est expliqué dans le compendium pour l’EDK, et depuis que l’EFI existe sur plateforme itanium, et qu’apple ont commencés a installer les premiers éléments de sécurisation du boot.



&nbsp;Et c’est pas de la crypto mais de l’admin sys.

&nbsp;Et c’est de la très mauvaise fois que de basher microsoft sur ce point : ils sont unique certificateurs par défaut parce que personne d’autre ne veux le faire, les industriels demandant des garanties juste impressionnantes.

&nbsp;De plus, la certification et la révocation, sont sur plateforme microsoft, juste transparente. C’est pas comme si l’OS avait accès a la partie dbx/KEK/KEXt de la nvram stockant les infos UEFI/Boot/BCD.

&nbsp;Et d’ailleurs, de ce point de vue, linux est une faille de sécurité a lui tout seul : lui y accède en dur via le shell.



&nbsp;Et là, entre nous, si tu&nbsp;t’intéresse&nbsp;un minimum au sujet, tu verra que l’utilisateur lambda tel que tu le décris ne pourra être impacté par ce genre de failles : faut un accès physique a la machine. Ca peut permettre de véroler un kiosk sous windows et de le démarrer en mode “admin”, mais dans les faits avant de pouvoir installer un malware qui ira te véroler l’OS, voir un OS vérolé tout court, y’a un gouffre.

&nbsp;Et non, ça ne sera jamais simple, car c’est une fonction qui peut bricker une carte mère. (modifier les db/PK demande d’aller directement éditer les bases dans les oproms contenant l’UEFI, et donc d’écrire en mode réel, et donc … de ne plus être en mesure de booter, du tout.).



&nbsp;Seule exception, les périph ARM qui ont leurs mécanismes par design sur une partoche spécifique du stockage de masse. Seul le POST est réalisé en hard (et intégré au SoC).









Edtech a écrit :



Tu ne veux pas mettre quelques sauts de lignes ? <img data-src=" />







et un lien valide également.. edit : oublie ca <img data-src=" />



j’aimerais comprendre tes propos, le point de vue technique, comme quoi tout se joue au plus bas niveau ..

au mieux, tu peux m’envoyer un mp? <img data-src=" />


votre avatar







KissFC a écrit :



&nbsp;De plus, la certification et la révocation, sont sur plateforme microsoft, juste transparente. C’est pas comme si l’OS avait accès a la partie dbx/KEK/KEXt de la nvram stockant les infos UEFI/Boot/BCD.

&nbsp;Et d’ailleurs, de ce point de vue, linux est une faille de sécurité a lui tout seul : lui y accède en dur via le shell.





Merci pour ton lien des plus instructifs (j’ignorais absolument tout de cela), mais je bute sur cette partie de ton message. Si les dbx/KEK/KEXt sont des clés publiques, quel est le problème ?



Edit: si, je crois comprendre : avec Linux, on peut ajouter et supprimer des clés tout seul sans appuyer sur F11 au démarrage, c’est ça ?


votre avatar

J’avais déjà survolé ton lien que tu avais mis dans un post précédent et je répète en plus clair : le problème n’est pas que gérer tout ce mécanisme de clés est infaisable, mais que d’un point de vue utilisateur, ce sera vu comme une forme de sabotage à coup de complexité inutilement excessive. 




 Microsoft se fait basher surtout parce qu'on se doute bien que prôner ce système sur les PC a pour but de démotiver l'utilisateur lambda qui  aurait l'audace d'installer un Linux qui n'aurait pas été signé (possible pour les distributions un peu moins grand public), sans  avoir d'abord coupé cette option. Or comme l'option devient... optionnel, normal qu'il soit accusé de vouloir nuire à la concurrence (au minimum).       







 Et celui qui veut installer un Linux a beau être un peu plus avancé ou motivé que  Mme Michu, ça ne fait pas de lui pour autant un administrateur système.  Comme ton lien parle que selon ton choix, on pourrait être amené à        


 devoir signer chaque kernel (de la maintenance régulière donc) etc,&nbsp; à la fin le triple ratio "temps investi/compléxité/gain perçu"  est extrémement défavorable au système Secure Boot.       







 Enfin bon je ne vais clairement pas me faire suer à créer des clés. Trop long. Trop rébartatif. La probabilité de chopper un rootkit infectant le bootloader est largement plus faible que de subir un Cryptolocker. J'ai donc mieux à faire.       







 Sinon :




C’est pas comme si l’OS avait accès a la partie dbx/KEK/KEXt de la nvram stockant les infos UEFI/Boot/BCD

Peut-être pas ça, mais après l’Anniversary Update, mon Secure Boot s’est remis en Windows UEFI alors que je suis persuadé de l’avoir réglé autrement. Je ne sais pas si c’est lié à l’update, ou si je n’aurai pas bêtement oublié de le retirer après une récente update du BIOS (c’est toujours possible). Mais ça ne retire pas l’impression que mon ordinateur appartiendrait plutôt à Microsoft Corp qu’à moi-même (il faut dire que W10 et ses mises à jour majeures remet par défaut certains réglages donc…).

votre avatar

à un moment ou à un autre t’achètes bien la carte mère non ?

(Même si c’est pour mettre un Linux)



Moi je vois une certification par un organisme européen ad hoc. Histoire de ne pas confier les clés du camion à une société américaine…

votre avatar







tazvld a écrit :



Yep, sauf que si tu lisais la news, ce n’est pas un backdoor que l’on parle ici, mais d’un debug mode.





Ouais, je n’ai lu que les multiples parties où l’on parle bien de porte dérobée (backdoor), y compris le titre de la niouze.<img data-src=" />


votre avatar







v1nce a écrit :



à un moment ou à un autre t’achètes bien la carte mère non ?

(Même si c’est pour mettre un Linux)





Oui, et ?


votre avatar

M$ est vraiment nul a chier. :eek:

votre avatar

Parfaitement dit.

La détection d’un support bootable (cd/dvd/clé usb) contenant un certificat devrait proposer l’insertion de ce certificat.

Bie sûr en précisant bien les implications de son acceptation et avec un mécanisme d’acceptation non trivial : taper “oui” (ou le CRC de la clé) et pas simplement entrée) &nbsp;&nbsp;

votre avatar

Et bien pour pouvoir être vendue en Europe toute carte mère &nbsp;disposant d’un mécanisme de sécurité devrait obligatoirement être préinstallée avec&nbsp;un certificat dont la gestion serait assuré par un organisme européen.

Au lieu de venir simplement avec le certificat MS de facto

votre avatar







v1nce a écrit :



Et bien pour pouvoir être vendue en Europe toute carte mère &nbsp;disposant d’un mécanisme de sécurité devrait obligatoirement être préinstallée avec&nbsp;un certificat dont la gestion serait assuré par un organisme européen.

Au lieu de venir simplement avec le certificat MS de facto







t’as oublié que l’Europe est favorable à l’embargo microsoft, notamment depuis qu’il est montré que windows “est dans l’interet de l’utilisateur final” ce qui a cassé totue chance d’avoir un choix de systeme en grande surface.


votre avatar







v1nce a écrit :



Moi je vois une certification par un organisme européen ad hoc. Histoire de ne pas confier les clés du camion à une société américaine…





D’après un post précédent qui semble avoir quelque connaissance sur l’UEFI, rien empêche l’existence d’un tel organisme. Il faut “juste” répondre au très fortes exigences que le consortium impose.







Ricard a écrit :



Ouais, je n’ai lu que les multiples parties où l’on parle bien de porte dérobée (backdoor), y compris le titre de la niouze.<img data-src=" />





Désolé, je n’ai pas lu (retenu en faite) le titre ( :P pour une fois que c’est dans ce sens ).



Mais toujours est-il, parler de backdoor pour un debugmod (plus un developper mode) qui s’est retrouvé dans la nature, c’est faire des grands écarts un peu osés… un peu plus et on aurait dit un politicien français qui n’ont aucun soucis pour parler du téléchargement illégale lors de débats sur le terrorisme.


votre avatar







KissFC a écrit :



Hein ? 



  C'est quoi ce vieux FUD que vous nous faites ?        


  Non parce que Windows ne demande qu'une chose : que le secure boot soit actif.        


  Il est parfaitement possible d'installer son propre jeu de clés persos, genre clés privées, publiques et tuti quanti et de faire ses propres certifs sans que windows ne dise rien.


http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html 



  Cadeau. ...




You must create three Secure Boot key sets (public and private), and for greatest flexibility, you’ll need several file formats—annoyingly, different programs require different file formats….



Bon ça va pas être simple&nbsp;



&nbsp;This example shows two warnings. I don’t claim to fully understand them, but they don’t seem to do any harm&nbsp;…



&nbsp;Ah merde si lui dont c’est le boulot ne comprend pas alors ça risque d’être compliqué&nbsp;



&nbsp;Some UEFIs provide the means to install your own keys using their own built-in user interfaces&nbsp;&nbsp;…



&nbsp;ah enfin des bons élèves&nbsp;&nbsp;&nbsp;but all three of the interfaces I’ve seen employ confusing terminology and are unintuitive in certain key respects&nbsp;&nbsp;Bon ben non alors.



&nbsp;To begin, you must find a way to enter the firmware setup utility. You can do this by hitting the Delete or F2 key on many computers just after you power them on, but this detail varies greatly between machines&nbsp;&nbsp;



&nbsp;Comment expliquer ça à Mme Michu en termes compréhensibles ?



&nbsp;The ASUS P8H77-I’s prompts are confusing once you opt to load or append a key from a file…



&nbsp;Zut charger une clé depuis un fichier c’est un peu ce que je voulais faire.&nbsp;&nbsp;&nbsp;



&nbsp;Warning:&nbsp;My ASUS P8H77-I will accept&nbsp;anything&nbsp;as a key file, but only a properly formatted file will actually work! If you mistakenly add a&nbsp;.crt&nbsp;file or something else, you might be confused when it doesn’t work….



&nbsp;Non ? sans rire ? confused ? C’était clair jusqu’à présent pourtant.&nbsp;&nbsp;&nbsp;



&nbsp;Là j’en suis à la moitié du document. Et Mme Michu elle ne sait toujours pas si elle doit faire F2 ou Esc pour entrer dans le BIOS&nbsp;&nbsp;&nbsp;



[HS]saleté d’éditeur de *£ù^) qui perd toute la mise en forme (ouf ça fait du bien) [/HS]


votre avatar

Exigences qui sont : faire partit des promoters. (http://uefi.org/members )

Avoir une procédure de validation visible par tous, disponible pour tous, le financement ne rentrant pas en compte. Que la procédure de validation soit acceptée par tout les promoters.

Que les certificats soient révocables, et de pouvoir répondre à toutes demandes.

D’avoir une procédure d’audit des codes, obligeant à la confidentialité mais qui soit suffisamment performante en termes sécuritaires pour pas valider n’importe quoi.

Que les certificats racines ne soient pas hébergés en interne.

Que les certificats racines et l’organisme de certification soit connu et reconnu de tous.



Bref … Pas a la portée du premier venu. Et vu le prix que fait raquer VeriSign a Microsoft, 99$ la clé KEK privée pour installer ses propres MOK et avoir son propre Shim, c’est pas cher payé.&nbsp;



Et n’en déplaise à la majorité, ceux qui ont poussés pour l’adoption du secure boot sont Apple, Intel, IBM et RedHat. Pas Microsoft.

votre avatar

Tu saute directement a la case “utiliser KeyTool”.

votre avatar

Et en plus je suis sûr que t’es sérieux en disant ça…

votre avatar







v1nce a écrit :



Et bien pour pouvoir être vendue en Europe toute carte mère  disposant d’un mécanisme de sécurité devrait obligatoirement être préinstallée avec un certificat dont la gestion serait assuré par un organisme européen.

Au lieu de venir simplement avec le certificat MS de facto





Oui, et ?

Je ne vois toujours pas ce que ça change. Dans tous les cas, on paie pour avoir le droit d’exécuter le code de notre choix (voire même notre propre code).

Tout ça n’est qu’une question de fric. Payer une fortune à Microsoft ou à une entreprise de certification, il n’y a absolument aucune différence. Dans les 2 cas tu auras ton certificat, si tu as les moyens de le payer.



Les entreprises de certification aussi peuvent pousser (corrompre) les fabricants de carte-mère à virer l’option de désactivation.

Quant au changement ou à la suppression des clés, ils peuvent très bien aussi l’empêcher.


votre avatar







KissFC a écrit :



Et n’en déplaise à la majorité, ceux qui ont poussés pour l’adoption du secure boot sont Apple, Intel, IBM et RedHat. Pas Microsoft.





C’est Microsoft qui l’a poussé pour les ordinateurs de particuliers depuis Windows 8.x via le « Programme de certification Microsoft » qui permet aux fabriquants d’apposer le petit logo avec la légende “Compatible Windows X” qu’on voit sur certains PC et boîtes de carte mère. Le pouvoir du marketing (ou de Mme Michu plus réceptive à ce logo qu’à d’autres explications) et le fait que la dite certification imposait l’introduction de Secure Boot, les fabriquants ont optempéré.



Car les noms que tu cites ont peut-être contribué, mais à l’exception d’Apple qui en reste une (un ordinateur Apple étant un écosystème fermé spécifique), et vu ce qu’est Secure Boot, c’était clairement orienté pour les professionnels uniquement car au sein d’une entreprise, son intêret est évident.



Microsoft a juste sauté sur l’occasion pour le forcer partout, et le fait de rendre l’option pour la couper “optionnel” pour la certification W10 alors qu’elle était obligatoire sur celle de W8 montre clairement la finalité de ce forçing. C’est juste de la nuisance commerciale.


votre avatar

Je te laisse voir les spec d’EFI sur Itanium, d’EFI sur matos Apple. Du blindage demandé par IBM sur leurs serveurs. Et les demandes de RedHat concernant l’UEFI, d’ailleurs, Shim, c’est pas un hasard si ça provient de RedHat (il était dans les cartons depuis un bout de temps, puisqu’ils ont bossés a l’intégration de x509 non seulement dans le kernel linux mais aussi dans l’EFI, c’est AUSSI pour ça que Linus l’a mauvaise concernant le secure boot.)

Le problème n’est encore une fois, pas la technologie en elle même, ni l’organisme certificateur.



Le problème ici, c’est, encore une fois, microsoft qui fait deux bourdes a laisser le mode debug, et une golden key kek dans la nature.



Braif.

Avant de crier au complotisme, faudrait déjà arrêter de regarder les faits de manière biaisées : hormis des suppositions sur se que voudrait microsoft. Le contrat VeriSign se chiffre en millions de dollar/ans pour “valider” une db et des PK. Le gain pour microsoft est quasi nul, la KEK a 99$ c’est vraiment économique, surtout pour RedHat avec son Shim du coup, si vous avez pas encore capté les mécanismes en jeu, même sans parler de la faille, vous avez, grâce a shim, la possibilité de signer vos kernel sans soucis avec un MOK. Mais il a été demandé a microsoft de devenir organisme certificateur, parce que personne n’avait (et n’a encore) l’équipe de dev a coller pour mater les boots process, drivers EFI et autre à valider.



Secure boot obligatoire ? A ma connaissance, il n’y a que les device arm qui IMPOSENT secure boot à l’heure actuelle. Je te laisse regarder se qu’en une bootchain et comment fonctionne un ordinateur a partir du POST jusqu’au log.



UEFI est plus simple a utiliser que BIOS. UEFI est carrément plus portable que BIOS. Et rien qu’un truc que vous avez pas encore compris : avec UEFI, c’est la FIN DES PROBLEMES D’ACPI/APIC et définition hasardeuses de matos dans une table obscure. La sécurité avec secure boot, c’était juste demandé par tout les acteurs un tant soit peu dans le coup. La mise en oeuvre vous plait pas ? Et bien faite en un vous même, proposez, si y’a autant de brouzouf a se faire, vous allez être millionnaires. (un indice : personne veux se mettre sur le créneau parce que c’est un service A PERTE).

Donc comme le BIOS : vous apprenez a utiliser l’UEFI et on en reparle au lieu de critiquer. D’ailleurs, je pense pas que les devs kernel linux soient mécontents d’être passés sur UEFI.

votre avatar







jb18v a écrit :



Genre hier ?



<img data-src=" />





oui voila exactement&nbsp;<img data-src=" />


votre avatar







ErGo_404 a écrit :



Ben Google et Apple aussi ont des failles dans leurs systèmes.

Si tu abandonnes un éditeur à la première bourde de sécurité, t’as pas fini de changer d’OS.





sauf qu’ici ce n’est pas une faille, mais une backdoor. Faire confiance à un système expressément équipé de backdoors ?


votre avatar

C’est plus une faille pour l’exclusivité de Microsoft sur une machine donnée que pour un utilisateur final. Pour l’exploiter il faut être en possession de la machine, cas pour lequel un chiffrage des données fera sans doute mieux qu’une impossibilité d’installer un jailbreak.



En plus, le terme porte dérobée laisse à penser que c’est un outil d’espionnage, ce qui n’est pas le cas (ou alors c’est ma définition qui en est trop réduite).



Après, oui, il y a une bourde technique sévère du point de vue respect du cahier des charges, mais l’utilisateur final n’a pas trop à s’en inquiéter, je pense.

votre avatar

Android sur un Lumia? Pas besoin de racheter un tel, qui fonctionne, pour jouer à Pokemon go? Cool!

votre avatar







le podoclaste a écrit :



Après, oui, il y a une bourde technique sévère du point de vue respect du cahier des charges, mais l’utilisateur final n’a pas trop à s’en inquiéter, je pense.





Il pourrait même s’en réjouir.


votre avatar

Super nouvelle, maintenant que (in)Secure Boot équipe la quasi-totalité des PC vendus…



Pourquoi est-ce qu’une telle nouvelle ne m’étonne pas ? <img data-src=" />







Il n’est pas exclu d’ailleurs que le FBI et d’autres agences profitent de cette erreur.





Dites que je suis parano, mais pour moi, il n’est pas impossible non plus que cette « erreur » ait été intentionnellement conçue par le FBI et/ou la NSA, en collaboration avec Microsoft.



2005 : début de la conception de l’UEFI, remplaçant du BIOS.



2011 : Microsoft annonce que les PC faisant tourner Windows 8 devront impérativement être équipés de Secure Boot, ce qui fait râler pas mal de monde (notamment du côté des distributions GNU/Linux, que Secure Boot risque d’empêcher de démarrer faute de clé valide).



2012 : ajout officiel de Secure Boot à la norme UEFI (Spec 2.3.1 Errata C).



2013 : début des révélations d’Edward Snowden.





Autrement dit cette backdoor a été introduite bien avant les révélations de Snowden… À une époque où l’on sait (grâce à Snowden justement) que Microsoft travaillait main dans la main avec la NSA. Alors, erreur ? Coïncidence ? On en saura peut-être plus à l’avenir…

votre avatar







jb18v a écrit :



Enorme <img data-src=" />



mais en pratique c’est jamais actif à 100% non ? toujours pu installer un autre OS non Microsoft sans problème (autre que faire gaffe à ses partitions et secteur de démarrage) <img data-src=" />







Normalement, sur un PC (architecture intel) tu dois être capable de désactiver le secure boot, c’est une obligation. Tu n’as donc pas de problème dessus.



Le seul problème viens des appareil ARM ont MS oblige que le secure boot soit obligatoirement non désactivable avec Windows 8. Bon, d’un autre coté, ce n’est pas comme si le reste de l’industrie font pareil (les grandes marques ont tendance à bloquer leur boot)







Ricard a écrit :



Comment ? Qu’est-ce que j’apprends ? Les backdoors sont des failles de sécurité ?

Je tombe des nues… <img data-src=" />





Yep, sauf que si tu lisais la news, ce n’est pas un backdoor que l’on parle ici, mais d’un debug mode.


votre avatar







vampire7 a écrit :



Je ne vois pas ce que ça change, entre payer Microsoft et payer une entreprise de certification.







Microsoft est à la fois vendeur d’OS (en concurrence avec d’autres), et celui qui certifie les machines. Tu ne vois pas le problème ?



C’est un peu comme si Volswagen avait en charge de faire les contrôles anti-pollution de tous les constructeurs, et de décider quel véhicule est « conforme » ou pas. Ça créerait une sacrée distorsion de concurrence tu ne crois pas ?



Ben là c’est pareil, Microsoft est juge et parti, et peut ainsi faire barrage aux autres OS. Ce serait infiniment plus sain si cette certification relevait d’une entité indépendante, ou au minimum, d’un consortium de plusieurs entreprises (incluant par exemple Microsoft, Google, Red Hat…).


votre avatar







le podoclaste a écrit :



C’est plus une faille pour l’exclusivité de Microsoft sur une machine donnée que pour un utilisateur final. Pour l’exploiter il faut être en possession de la machine, cas pour lequel un chiffrage des données fera sans doute mieux qu’une impossibilité d’installer un jailbreak.



En plus, le terme porte dérobée laisse à penser que c’est un outil d’espionnage, ce qui n’est pas le cas (ou alors c’est ma définition qui en est trop réduite).



Après, oui, il y a une bourde technique sévère du point de vue respect du cahier des charges, mais l’utilisateur final n’a pas trop à s’en inquiéter, je pense.





Ils étaient prêt à tout pour faire passer à 10, y a-t-il causes et effets ? (j’ai toujours mon 7)<img data-src=" />


votre avatar

Hein ?

C’est quoi ce vieux FUD que vous nous faites ?

Non parce que Windows ne demande qu’une chose : que le secure boot soit actif.

Il est parfaitement possible d’installer son propre jeu de clés persos, genre clés privées, publiques et tuti quanti et de faire ses propres certifs sans que windows ne dise rien.

http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html

Cadeau.

Et vous pouvez du coup, dire “merde” a cette faille lolesque : personne n’ira installer d’autres clés que les votre. En revanche, là ou c’est problématique, c’est que cette faille permette de démarrer windows en mode secure, sans l’être. Et ça, c’est pas un problème de secure boot, mais de windows.



Edit : et bien entendu avec vos propres KEK et db/dbx, la goldenkey de microsoft, ben elle existe plus.

votre avatar

Cool story… mais heu… c’est quand qu’on parle de backdoor là ?

Surtout je ne vois pas trop le rapport entre le secure boot et le backdoor. Le secure boot à pour but de garantir qu’il n’y a aucun logiciel qui s’est lancé entre le “BIOS/UEFI” et l’OS afin de réduire le risque de logiciel malveillant.

Dans le pire des cas, si il y a un backdoor dans le secure boot, ça revient au même que l’absence secure boot. Ainsi, le secure boot n’est pas un danger supplémentaire d’intrusion par rapport à son absence.

votre avatar

mode conspiration ou pas

&nbsp;

&nbsp;J’arrivais avec mon Win 7 à jouer avec une fluidité acceptable au dernier Tombraider (rise of..), aujourd’hui avec toujours mon Win 7, c’est moins bien, que s’est-il passé depuis que les màj pour forcer à passer à 10.

&nbsp;Mon PC est plus&nbsp; lent. Un bon nettoyage s’impose <img data-src=" />si j’y arrive <img data-src=" />

votre avatar







le-gros-bug a écrit :



Pourquoi chercher plus compliqué ? <img data-src=" />





Parce que c’est plus simple !


votre avatar

Il n’y a pas de backdoor dans le secure boot. Le seul backdoor ici c’est : goldenkey dans la nature pour microsoft et ses certifs, et windows qui boot en mode debug. Secureboot n’est pas impacté.

Tu change tes clés, tu force les clés BCD secure et tu efface toute les entrées merdique, tu change les db/dbx et t’es peinard.

votre avatar







Konrad a écrit :



Microsoft est à la fois vendeur d’OS (en concurrence avec d’autres), et celui qui certifie les machines. Tu ne vois pas le problème ?





J’y verrais un problème si je pensais que les entreprises de certification sont incorruptibles et indépendantes, ce qui n’est pas le cas.


votre avatar

Ouais mais faut voir l’intérêt du truc&nbsp; avant de voir le complot…



Empecher un OS de booté sur un produit vendu avec du Windows à l’intérieur. Pas sur que la NSA ou FBI avait ce besoin. Par compte si ça donnait la possibilité à une backdoor dans lequel un malware ou autre pouvait se faufiler là ouai.



La seule personne à qui ça pose préjudice est Microsoft. Je crois pas que voir une machine Surface fonctionnait sous android leur ferai plaisir :-/

votre avatar







Aqua-Niki a écrit :



J’ai vu plusieurs petits PC (hybrides ou PC de taille similaire) sur lesquels ça empêchait d’installer Ubuntu. Et l’article parle aussi des smartphones Lumia pour lesquels il y a de grandes chances que ce soit actif à 100%.





Si c’est un PC x86/x64 ce devrait normalement être possible de désactiver le secure boot. Et quand bien même il ne serait pas désactivable, Ubuntu a normalement une clé valide.



Donc si tu as un problème, ce n’est très certainement pas le secure boot.

J’ai eu du mal à installer ubuntu sur mon premier PC avec UEFI. Mon erreur était que je voulais passer par Grub pour choisir l’OS, ce qui ne marchait pas, en effet, il faut utiliser directement la fonctionnalité de l’UEFI pour ce faire.

Ensuite, il y a plein de petits pièges à bien faire attention : démarrer son live CD/USB en mode UEFI pour être sûr que l’OS soit installer utilise le boot UEFI, certain PC proposant de démarrer les liveCD/USB en mode Legacy (BIOS) par défaut (ce qui fait que l’OS s’installe comme si il était devant un BIOS).


votre avatar







tazvld a écrit :



Si c’est un PC x86/x64 ce devrait normalement être possible de désactiver le secure boot. Et quand bien même il ne serait pas désactivable, Ubuntu a normalement une clé valide.





Ça dépend. Sur les machines OEM depuis Windaube 10, cette option n’est plus obligatoire mais les fabriquants peuvent toujours la mettre… ou pas donc.



Evidemment si on achète sa machine pièce par pièce, l’option y sera très certainement mais parfois de façon détourné. Sur ma mobo ASUS H97M-E, il n’y a pas d’option nommé comme tel pour ça dans la section Secure Boot. Il faut aller dans le menu de gestion des clés pour les effacer et seulement là c’est désactivé, ce qui m’a laissé penser au début que je ne pouvais pas le couper. Une confusion souhaitée ?


votre avatar







le podoclaste a écrit :



C’est le cas, pourtant.







Pour l’UEFI oui, mais pour les clés Secure Boot, non : seuls les OS certifiés par Microsoft peuvent démarrer quand le Secure Boot est activé. Les prix vont de 1500 à 70000 Dollars pour une clé. On comprend pourquoi les autres OS ont tiré la gueule.



Alors certes chacun peut créer sa clé dans son coin comme cela a été mentionné, mais il faut admettre que ce n’est pas à la portée de tout le monde. Ce serait vachement plus simple si les clés étaient gérées par un consortium.


votre avatar







SLV17 a écrit :



voila qui ressemble à une signature ;) :







En fait, non. Ce sont les empreintes (message digest) des “Bootmgr.efi” qui ont été révoqués.



google “Disallow db (DBX)”


votre avatar

Si j’ai bien compris, ca ne changera pas grand chose…

Rien n’empeche une distro linux, voire un utilisateur de modifier, recompiler et installer une version modifiée d’un élément de boot de ton système (grub, kernel, autre?).

Et cet élément modifié ne sera jamais signé par quiconque de reconnu. (exception pour les distros qui se seront faites connaitre par ton consortium)

(OK, un utilisateur, y a peu de chance que ca arrive, mais une distro, pq pas…)



Bonus si tu trouves une solution pour les distribs sources comme gentoo pour signer tes binaires sans avoir leurs clés (si ils en avaient) !

&nbsp;

&nbsp;=&gt; à moins de le faire avec tes propres clés et de les ajouter dans le hard, c’est mort. Et on en revient a ce qui est expliqué plus haut.



Et ton consortium, c’est lui qui va aller voir les constructeurs de CM pour leur filer les clés des différentes distros qui ont été lui demander d’être reconnus ?

votre avatar







Konrad a écrit :



Pour l’UEFI oui, mais pour les clés Secure Boot, non : seuls les OS certifiés par Microsoft peuvent démarrer quand le Secure Boot est activé. Les prix vont de 1500 à 70000 Dollars pour une clé. On comprend pourquoi les autres OS ont tiré la gueule.



Alors certes chacun peut créer sa clé dans son coin comme cela a été mentionné, mais il faut admettre que ce n’est pas à la portée de tout le monde. Ce serait vachement plus simple si les clés étaient gérées par un consortium.





Non :

Microsoft sont les seuls certificateurs car ils sont les seuls a proposer des garanties pour que la certification soit considérée comme fiable par l’industrie.

Mais SB a été poussé par les fabricants de smartphone, RedHat, Apple, IBM, pas microsoft.

DEAL

WITH&nbsp;

IT

Au lieu de raconter de la merde.



Une clé KEK chez microsoft c’est 99$ pas 1500 a 70000. Ce prix c’est pour un HSM (Hardware Security Module). Soit un ordinateur certifié qui te permet de booter une infrastructure totalement sécurisée (une sorte de TPM INFRA), c’est généralement utilisé dans des centres de données genre OVH sur leurs infra cloud, du stockage en big data, les OEM genre Lenovo/Asus pour avoir le droit de faire et fournir des golds au publique … Sur des solutions a plusieurs millions de brouzoufs juste pour une baie @42U.



Toi en tant qu’utilisateur final (et encore, microsoft te signera jamais une clé pour tes beaux yeux, il faut être une organisation) :&nbsphttps://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/pre-s… c’est ça qui t’intéresse. Et le dernier état de l’art en matière de secure boot est ici :&nbsphttp://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_2013_-_New_Orlea…



Document qui mentionne au passage l’existence d’une autorité interne de certification reconnue mais non disponible au publique : canonical.

Bon maintenant, si on reprend en détail l’article, ça parle principalement de mode debug sur des devices qui ne sont pas vraiment des windows 10 “mainstream” mais plutôt des machines type portable, windows RT etc …

Et que les failles ont été introduites a la mise à jour pour redstone : c’est pas une backdoor en tant que tel mais une infra de mise à jour détournée de son utilisation et laissée en l’état sur les devices.



Et en passant, il ne faut pas un mais trois (3!!!) reboots pour mettre en place cette infra de manière totalement fonctionnelle avec validations de la part de l’utilisateur final, genre le truc super discret quoi. Et c’est, comme précisé dans l’article, pas comme si tu pouvais pas non plus passer ton device en mode nontrusted de manière hard, et pas comme si tu pouvais pas désactiver secureboot sur les ordinateurs individuels.



Braif … Le FUD prend bien a se que je vois et en plus il est poussé par des personnes qui auraient plutôt tout intérêt a bosser avec MS plutôt que contre.



PS : si vous êtes pas content de la manière dont est implémenté secureboot par votre OEM/Fabricant de matos, libre a vous de vous tourner vers des fabricants “responsables” : gigabyte, CM “anyOS” style QUO computer, installer coreboot, faire vous même vos propres UEFI, hacker votre UEFI via mmtools … Braif, les solutions ne manquent pas.


votre avatar

Je me permet une grosse correction :&nbsp; SecureBoot poussé par RedHat… Il me semble que c’est réécrire l’histoire ! (et dans ta page parlant d’UEFI en général, ils ne sont pas promoters mais contributors)



Ils ont été les premiers à soulever le problème que posera SecureBoot sur les machines certifiées Win8.

Ensuite il y a eu 2 solutions qui ont été bossées en parallèle pour les distributions linux :




  1. RedHat qui a fait certifier un first stage bootloader par MS histoire de pas être emmerdé par le matos (mais dans un sens, ils se rendent dépendant de MS)

  2. Canonical qui a fait certifier des clés pour inclusion dans le matos et être reconnu par SecureBoot, à coté des clés de MS. (ce que tous les fabricants n’ont probablement pas inclus)



    Pas vraiment ce qu’on peut appeler des encouragements vers SB…

    &nbsp;

    Si mes souvenirs ne sont plus corrects, corrigez moi, mais il me semble que c’est ca.

votre avatar

Grosso modo, c’est ça. Hormis qu’ils ont bien poussés en tant que contrib a l’adoption de SB pour une raison : securiser des firmware (comprendre firmware dans le sens association matériel + logiciel créés et bloqués par des firmes/industriels). Pour une raison simple : ils sont les premiers pourvoyeurs de solutions sécurisées “open source” pour le gourvernement US. Miscrosoft arrive bien après ceux mentionnés.



Pour les solutions, il y à en réalité 3 :

-Shim, poussé par RedHat et canonical.

-PreLoader signé par MS pour la Linux Foundation.

-Canonical qui fait signer ses kernels en passant par les mêmes certifs que MS auprès de VeriSign/Symantec (ils ont les mêmes signatures hash)



Actuellement, les premiers “promoters” de SB sont même pas les promoters de UEFI mais les fabricants de portables, IoT et autres single board computer : ça leurs permet de contrôler se qui tourne sur leurs machines (chose que microsoft, par design, ne peut pas faire, même si ils aimeraient et à la condition qu’ils le veuillent).

votre avatar

Et toujours si je ne me trompe pas :




  • les PCs vont jusqu’au bootloader

  • les smartphones & co vont jusqu’à l’OS (avec les protections/restrictions plus ou moins fortes) voire même les applications (via market imposé, etc…)



    Il reste à l’intégrer dans les données utilisateurs (ou via les clouds) et on verra qu’un concept comme palladium, ca met 15 à 20 ans pour se mettre en place.

votre avatar

Techniquement, non, tout device peut être locké par firmware de bout en bout de la chaine : CF l’utilité d’une puce type Nuvoton, IPMI management board et autres concepts de management OOB et BMC. Hormis que les canaux ne sont pas pour le moment signés de manière obligatoire.

Il y a des POC qui circulent sur du trusted computing.



Pour voir des trucs vraiment crasses faut plutôt aller jeter un oeuil direction TCG, TPM et autre&nbsphttp://www.trustedcomputinggroup.org/ ou là, on parle vraiment de cadenasser l’infra et les device.

http://www.iotsworldcongress.com/ge-intel-microsoft-mit-red-hat-schneider-and-th…

Vous comprendrez que SB n’est pas un enjeux prioritaire : ils ont autre chose a se foutre sous la dent (généralisation d’Opal dans les puces Nuvoton, TPM a tout les niveaux)&nbsp;<img data-src=" />

votre avatar







matroska a écrit :



J’ai cru lire que tu étais tombé tout nu !



<img data-src=" />





Ca m’est déjà arrivé lors de soirées bien arrosées.<img data-src=" />


votre avatar

Ca reste les mêmes concepts en version light pour le moment, contournable, histoire de pas faire gueuler les acheteurs, habituer la population.



Mais je continue de croire que c’est malheureusement la tendance générale au nom d’une certaine “sécurité”.

votre avatar

Il y a des concepts sympathiques, reste a savoir combien de temps l’utilisateur final d’un produit restera concerné.

Je fait partie des rares fouteurs de merde dans ce genre de consortiums, en revanche, j’exècre le fait de cracher sur la technologie pour des problèmes philosophiques. La technologie est neutre jusqu’à présent, et le soucis : plus les gens cracheront dessus, plus les industriels feront tout pour passer en force avec des éléments techniques où justement, les mecs comme moi n’auront plus leurs mots a dire. Et donc, moins la technologie sera neutre (et génératrice de problèmes d’administration.)



Faut bien comprendre qu’il faut une évolution, le mieux restant de laisser aux gens dont c’est leurs travail, le faire et pas coller des assertions juste par principe : ça ne fait que modifier les opinions mais pas le fondement. Le fond est “honnête”, la résultante l’est moins, et le sera de moins en moins, parce que l’utilisateur final refuse de faire sa part de taff : apprendre a utiliser le système.

votre avatar







KissFC a écrit :



D’ailleurs, je pense pas que les devs kernel linux soient mécontents d’être passés sur UEFI.







jme suis jamais plaint de l’uefi.. je connais beaucoup de monde qui se sont sentis agacé par le faible nombre d’os supportant cette évolution quand c’est sortit (~2010) : cad que xp s’installait encore pas mal à ces années parce que 7 venait de sortir de la soucoupe, et qu’xp supportait pas l’efi.. beaucoup on configuré en legaci.

pour ma part j’avais pris 7, et le rare linux qui supportait l’efi, soit fedora. yen avait d’autres (ubuntu, version internationale) mais les moins connus l’étaient evidemment pas..



l’efi est une bonne évolution à mon sens : sécurité certes, mais surtout temps de boot plus rapide, flexibilité, gestion des GPT..

je voyais un peu ca comme maintenant je vois ipv6.. ca fait changer littéralement les choses, les sysadmin flippent mais quand on commence à comprendre et à s’approprier les méthodes ca passe comme une lettre à la poste.


votre avatar

Je suis sysadmin. Et je préfère 100 fois plus UEFI que BIOS.

votre avatar







KissFC a écrit :



Je suis sysadmin. Et je préfère 100 fois plus UEFI que BIOS.







L’UEFI ne m’a jamais posé de problème, et ça accélère vraiment beaucoup le boot. Rien à redire sur l’UEFI, il rend vraiment de grands services.



En revanche Secure Boot m’a régulièrement posé problème à l’install d’une distro GNU/Linux, en général je le désactive dans les paramètres de l’UEFI.



Je n’ai pas le niveau technique pour comprendre tout ce que tu dis sur la génération de clés Secure Boot, mais je veux bien admettre qu’il est possible d’être sa propre autorité de certification et de se passer de Microsoft. Dans le même temps, j’admets aussi que cela dépasse mes compétences, et que j’ai autre chose à faire que de me former là-dessus.



Alors peut-être que quelqu’un comme toi considère que je fais partie des « utilisateurs qui ne font pas leur part du taff : apprendre à utiliser le système ». Personnellement je considère qu’à ce niveau là d’intégration hardware, ce n’est pas à l’utilisateur final (i.e. moi) de s’approprier le truc ou de le hacker. L’utilisateur final faisait déjà des choses avant (par ex. installer une distrib GNU/Linux), et Secure Boot ne devrait pas l’en empêcher ni le rendre plus difficile que ça ne l’était. Une technologie est peut-être « neutre », mais pour moi, si elle met des bâtons dans les roues de l’utilisateur, c’est qu’elle a été mal conçue ou mal implémentée.



Just my opinion.


votre avatar

L’implémentation est laissée libre aux intégrateurs, OEM et fabricants de CM. Le problème n’est pas Microsoft mais les intégrateurs, OEM et fabricants de CM.



SB n’est qu’un élément d’un tout, UEFI a simplifié et formaté les choses : c’est un standard. Avant, c’était bien pire : une table ACPI mal fichu t’empêchait d’installer ta distro sur certains mobales. Comme le dit Linus, le problème n’est pas SB, Linux supporte le x509 (et ce de manière active puisque les devs kernels sont les principaux contributeurs), mais l’implémentation qui n’a pas été standardisée.

Si tu prend tianocore de base, le module secure boot se résume a intégration de certifs x509, une fonction sha256 pour le hash, db et dbx. Microsoft demande une interface compilée avec leurs compilo UEFI maison avec un flag mft sur le module, et que le binaire soit signé via HSM. Y’a pas de standardisation. CoreBoot a techniquement un moteur de gestion de signatures qui permet d’avoir un secureboot fonctionnel mais pas de clés MS intégrées : c’est pas standard encore une fois.

Donc les fabricants de CM/OEM/Intégrateurs font se qui va leurs rapporter des brouzoufs : certif microsoft même si c’est pas standard et basta.



Le soucis, c’est que si les utilisateurs ne poussent pas a demander un standard avec une gestion centralisée documentée, MS se bougera pas et les fabricants de CM non plus, la réponse que les utilisateurs sortent c’est “je désactive SB” ou “je passe en legacy + CSM” (se qui est encore pire). Quant tu vois des systèmes comme GPT + EFS + stack drivers .efi sous utilisés, qu’on conseille d’utiliser grub et de rester en mode legacy pour 99% des tutos, ça fait peur. “c’est compliqué” : Non, c’est carrément plus simple, UEFI détecte lui même les bootloader, et le chainloading n’existe plus. Grub/Elilo/Whatever, ça ne sert plus a rien en réalité : l’amorçage en UEFI n’existe pas. Suffit juste d’un manager (soit intégré a la CM soit custom style refind/BCDmanager de microsoft).

C’est tellement simple que ça permet de faire du stateless dès le PE.



Moralité, c’est pas après microsoft qu’il faut gueulé, mais après asus, gigabyte, whatever, de supporter le soft.

votre avatar







KissFC a écrit :



Je suis sysadmin. Et je préfère 100 fois plus UEFI que BIOS.





Tu fais constamment l’association entre UEFI et SB. Or, l’UEFI est totalement indépendant, et fonctionne très bien sans secure boot. C’est comme si tu utilisais l’UEFI comme argument positif pour justifier le vérouillage imposé par Secure Boot.



Et puis, qu’importe si Red Hat, Canonical soutiennent le Secure Boot (ce qui encore une fois est faux sur le principe, ils se sont simplement adaptés par la force des choses). Cela fait chier les petites distros / OS alternatifs, et permettra de lier encore un peu plus OS et matériel, ce qui est une hérésie.



Déjà, des produits comme l’iPhone, le Kindle Fire, etc qui empêchent de modifier le logiciel, auraient dû soulever le débat. Cela n’a pas été le cas parce que “cétrokool” ou “cépacher”. SB n’est que dans la continuité.


Secure Boot : Microsoft a laissé une porte dérobée ouverte

  • Oups

  • Un problème qui ne pourra peut-être pas être complètement résolu

  • Les portes dérobées sécurisées n'existent pas

Fermer