Secure Boot : VeraCrypt 1.18a résout des soucis avec l’Anniversary Update de Windows 10

Secure Boot : VeraCrypt 1.18a résout des soucis avec l’Anniversary Update de Windows 10

Après le certificat d'études, le certificat de boot

Avatar de l'auteur
Guénaël Pépin

Publié dans

Logiciel

19/08/2016 4 minutes
55

Secure Boot : VeraCrypt 1.18a résout des soucis avec l’Anniversary Update de Windows 10

Hier, la version 1.18 de VeraCrypt introduisait le chiffrement des disques sur les terminaux en UEFI. Problème : Secure Boot bloquait son pilote sur les nouvelles installations de Windows 10 avec l'Anniversary Update. La version 1.18a règle le problème.

Malgré son nom, Secure Boot peut parfois aller à l'encontre de la sécurité. Hier, VeraCrypt 1.18 était publié, en introduisant le chiffrement UEFI, une fonction voulue de longue date par ses développeurs (voir notre actualité). L'étape était importante, le logiciel testé de longue date mais quelques soucis restent.

Les plus importants problèmes sont liés à Secure Boot, une sacrée épine dans le pied du projet open source. Le principal a été réglé dans la version 1.18a, publiée ce matin, avec une concession au géant de Redmond. Les moutures Linux et macOS restent en 1.18, n'étant pas concernées par le souci.

L'Anniversary Update plus stricte sur la signature des pilotes

Dans la journée, des utilisateurs ont remonté un souci bloquant : impossible d'utiliser VeraCrypt 1.18 sur une nouvelle installation de Windows 10 avec l'Anniversary Update si Secure Boot est activé. La raison : le pilote qu'utilise le logiciel pour fonctionner n'a pas été signé par Microsoft et est donc bloqué par Windows. « Il n'y a pas d'erreur de la 1.18 sur Windows 10 Anniversary Edition si on a fait une mise à jour vers cette nouvelle version » nous précise Mounir Idrassi, le développeur principal de VeraCrypt (voir notre entretien).

Introduit avec Windows 8, Secure Boot permet de vérifier l'intégrité de la chaine de démarrage pour que rien de malveillant ne puisse s'y insérer, comme des rootkits. La fonction est liée à l'UEFI, le successeur du BIOS qui ne dispose pas de cette sécurité.

Depuis l'Anniversary Update, Windows 10 n'accepte plus que les pilotes signés par Microsoft si Secure Boot est actif. L'exception : les pilotes qui disposent d'un certificat de signature émis avant le 21 juillet 2015. Manque de chance, celui utilisé par VeraCrypt 1.18 est bien ultérieur à cette date, le précédent ayant expiré en avril dernier. Il a donc fallu attendre que des utilisateurs avec un terminal équipé d'un UEFI et installant la dernière version de Windows 10 se manifestent pour constater le problème.

VeraCrypt 1.18a toujours peu compatible avec Secure Boot

Bon gré mal gré, Mounir Idrassi a dû se décider à une concession à Microsoft. Il a obtenu de l'éditeur une signature de son pilote, dans la nuit. Un processus qui a pris moins de deux heures.  Ce pilote nouvellement adoubé a été introduit dans la version 1.18a publiée ce matin. « J'aurais aimé éviter cela mais Microsoft ne nous laisse pas le choix » confie-t-il.

Dans l'absolu, cela règle uniquement le problème d'installation de VeraCrypt sur la nouvelle version de Windows 10. Car pour chiffrer, le chargeur de démarrage (bootloader) du logiciel doit aussi être signé par Microsoft pour que Secure Boot le laisse se lancer. Or, Microsoft n'a pas signé celui de VeraCrypt. En clair : si le pilote signé permet l'installation de VeraCrypt, le logiciel ne peut toujours pas chiffrer à cause de Secure Boot, qui le bloque dans son démarrage.

Deux solutions s'offrent alors à l'utilisateur. La plus simple est de couper Secure Boot dans l'UEFI. Le mécanisme de sécurité disparait, mais VeraCrypt a le champ libre pour chiffrer. La seconde, plus technique, consiste à obliger Secure Boot d'accepter VeraCrypt, avec la signature de ses développeurs.

Pour cela, il faut passer Secure Boot en mode « custom » dans l'UEFI, revenir à Windows et entrer une commande Powershell (« powershell -File sb_set_siglists.ps1 »). Les instructions détaillées sont disponibles dans la documentation.

Rappelons que s'il aide bien à sécuriser le démarrage du PC, Secure Boot est loin d'être exempt de reproches. Il a été récemment découvert que Microsoft y a introduit une porte dérobée créée pour les tests des partenaires... Clés qui ont fuité, même si l'exploitation de cette bourde par un malware semble impossible, à moins d'insérer des pilotes malveillants. Le serrage de vis sur ces derniers avec l'Anniversary Update en est d'ailleurs une conséquence directe.

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

L'Anniversary Update plus stricte sur la signature des pilotes

VeraCrypt 1.18a toujours peu compatible avec Secure Boot

Commentaires (55)


Il y a un intérêt à laisser Secure Boot si on utilise Veracrypt ?



Vu le bordel que c’est de faire cohabiter les deux…

 


Les deux étant des mécanismes de protection différents pour des cas d’attaques différents, dans l’absolu, je dirais que oui.


Ça ne m’étonne pas. Cette “Anniversary Update” fait beaucoup parler d’elle - et pas forcément en bien - et semble “casser” pas mal de choses. C’est presque comme une nouvelle version de Windows, ou dans une moindre mesure un SP.


On a le même problème avec Dokan :(https://github.com/dokan-dev/dokany

Nous allons faire la demande de signature chez Microsoft en espérant que cela va

prendre 2hr comme eu…



<img data-src=" /><img data-src=" /><img data-src=" />


<img data-src=" />








Vekin a écrit :



Ça ne m’étonne pas. Cette “Anniversary Update” fait beaucoup parler d’elle - et pas forcément en bien - et semble “casser” pas mal de choses. C’est presque comme une nouvelle version de Windows, ou dans une moindre mesure un SP.





Elle est d’ailleurs impossible à déployer via WSUS, malgré un KB qui change rien, et un type MIME à rajouter dans IIS; on a une belle erreur 0xc1800118&nbsp;<img data-src=" />



Pendant ce temps à Vera Crypt…








Vekin a écrit :



Ça ne m’étonne pas. Cette “Anniversary Update” fait beaucoup parler d’elle - et pas forcément en bien - et semble “casser” pas mal de choses. C’est presque comme une nouvelle version de Windows, ou dans une moindre mesure un SP.





C’est le cas. C’était déjà le problème de la 15xx qui venait remplacer la première version commercial. Ce que Microsoft fait passer pour une “mise à jour” est en fait un remplacement du système par un autre système qui n’est pas tout à fait compatible, d’où le fait qu’il y a des logiciels et des drivers qui ne fonctionnent plus.

&nbsp;

C’est un des plus gros reproches que j’ai à faire sur Windows depuis qu’il est en rolling release. C’est d’autant plus problématique pour les personnes qui ne connaissent pas la différence et qui font la mise à jour sans avoir conscience que cela peut casser quelque chose. Pour les avertis, le problème est plus philosophique / idéologique : de quel droit Microsoft se permet-il de changer le système d’exploitation sans l’accord de l’utilisateur ?



Pour le nouveau driver de driversCloud j’ai le même problème. Si secure boot est activé et que la 1607 n’est pas issue d’une mise à jour les cross certificat ne marchent plus.

J’avais déjà un EV certificat .

Par contre la procédure HCK(WHQL) est particulièrement casse burne je l’ai faite il y a deux ans. il faut impérativement un windows serveur +2 machines clientes (x86 et x64) pour les tests. Après c’est gratuit depuis un deux ans environ maintenant.(pas le certif EV par contre <img data-src=" /> )


@charon.G Je ne crois pas que le WHQL est obligatoire ici.

Le blog ne dit rien justement par rapport a cela

https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/drive…








eglyn a écrit :



Il y a un intérêt à laisser Secure Boot si on utilise Veracrypt ?



Vu le bordel que c’est de faire cohabiter les deux…







Le top serait de pouvoir utiliser les 2 en même temps. L’intérêt d’un disque dur crypté est nul si au démarrage de la machine on arrive à l’infecter d’un quelconque mouchard qui se lance dans les premieres séquences de boot.









Vekin a écrit :



Ça ne m’étonne pas. Cette “Anniversary Update” fait beaucoup parler d’elle - et pas forcément en bien - et semble “casser” pas mal de choses. C’est presque comme une nouvelle version de Windows, ou dans une moindre mesure un SP.





Ben de ce que j’ai compris de la stratégie de MS sur Windows 10, l’Anniversary Update est plus une nouvelle version qu’un SP. D’après MS, Windows 10 serait le dernier Windows. Ils ont choisi de faire une évolution continu de leur OS par plein de petite mise à jours plutôt que faire des gros changement séparer par de longues périodes. Ils se rapprochent ainsi plus du système de développement de MacOS (ou Ubuntu).



Un tel développement a ainsi l’avantage de proposer régulièrement qu’une poignée de nouvelle fonctionnalité qui a plus de chance d’être explorer que si tu en balançais tout plein d’un seul coup. De plus, cela permet aux utilisateurs d’adopter avec douceur les nouveautés et pas se retrouver bête devant une toute nouvelle interface qu’ils ne comprennent pas et commence à pester dessus en masse.





all new Windows 10 kernel mode drivers must be submitted to the Windows Hardware Developer Center Dashboard portal (Dev Portal)



Hélas si. Je crois qu’ils veulent rendre obligatoire la certification . je suis inscrit sur ce portail(l’ancien nom c’était WinQual) et je n’ai rien vu sur la home pour signer les drivers sans certif HLK. De plus pour utiliser les services du portail il faut un certif EV reconnu.


En fait il y a peut être un nouveau truc Je vais valider les contrats pour voir:

http://hpics.li/73ba21f








tazvld a écrit :



De plus, cela permet aux utilisateurs d’adopter avec douceur les nouveautés et pas se retrouver bête devant une toute nouvelle interface qu’ils ne comprennent pas et commence à pester dessus en masse.





Un avantage pour les utilisateurs, mais une galère pour les développeurs. Finalement, c’est pas si différent d’un changement d’OS, sachant que certains programmes peuvent être “cassés” ensuite.



Ça va être la joie dans les hotlines <img data-src=" />



“Vous utilisez quelle version de Windows ?”

“Windows 10”

“Oui, mais quelle update ?”

“Euh, j’en sais rien. C’est quoi une update ?”



Merci pour le lien !

&gt;An attestation signed driver will only work for Windows 10 Desktop, it

will not work for other versions of Windows, such as Windows Server

2016, Windows 8.1, or Windows 7.



Cela veut-il dire que le WHQL est obligatoire pour Windows Server

2016 :( ?



Le WHQL est il difficule a passer ? Notre driver ne crache pas mais est egalement pas tres standard <img data-src=" />


Je n’ai pas fait gaffe pour 2016 j’en sais rien.

Pour le whql tu dois utiliser un logiciel sur serveur qui communique avec les windows clients qui vont effectuer directement les tests. Selon le type de driver il va tester une série de features. je pense que tu trouveras la liste sur msdn. Si un seul test échoue ton driver n’est pas validé. Si tous les tests passent le logiciel serveur va te créer un fichier résultat signé. Tu l’envoies sur sysdev et c’est validé automatiquement par des machines apparemment.

Dans mon cas ce n’était pas compliqué car ce n’était pas un driver qui correspondait à un matériel précis. Du coup il a effectué que les tests de base.

PS: Mon driver est en cours de validation








tazvld a écrit :



Le top serait de pouvoir utiliser les 2 en même temps. L’intérêt d’un disque dur crypté est nul



Tu pouvais t’arrêter là <img data-src=" />

Par contre celui d’un disque dur chiffré l’est moins… <img data-src=" />



Rien à foutre https://www.youtube.com/watch?v=C3rDVBm0OXE




Rappelons que s’il aide bien à sécuriser le démarrage du PC, Secure Boot est loin d’être exempt de reproches





Le principal problème de “Secure Boot” tel qu’il est implémenté, c’est qu’il veut bien faire confiance aux grandes entreprises (constructeurs, éditeurs) mais qu’il exclut totalement de faire confiance à l’utilisateur.



On le voit ici. Même si un utilisateur accorde sa confiance a VeraCrypt, l’utilisateur n’a aucun moyen d’ajouter VeraCrypt dans la chaine de confiance existante.



C’est une sorte d’UAC où seule une poignée d’entreprises ont le droit d’appuyer sur le bouton “toujours faire confiance a ce programme”.


Ah mais si ma pauvre dame,

Windows 10 indique dans les 100 pages de conditions d’utilisation que tout peut être mis à jour sans prévenir,

et que des fonctionnalités désactivées peuvent être remises en route.








Patch a écrit :



Tu pouvais t’arrêter là <img data-src=" />

Par contre celui d’un disque dur chiffré l’est moins… <img data-src=" />





Là, tu joue sur les mots, surtout que four chiffrer/crypterc’est grosso modo la même chose, par contre déchiffrer et décrypter sont différents de mémoire.





127.0.0.1 a écrit :



Le principal problème de “Secure Boot” tel qu’il est implémenté, c’est qu’il veut bien faire confiance aux grandes entreprises (constructeurs, éditeurs) mais qu’il exclut totalement de faire confiance à l’utilisateur.



On le voit ici. Même si un utilisateur accorde sa confiance a VeraCrypt, l’utilisateur n’a aucun moyen d’ajouter VeraCrypt dans la chaine de confiance existante.



C’est une sorte d’UAC où seule une poignée d’entreprises ont le droit d’appuyer sur le bouton “toujours faire confiance a ce programme”.





En même temps, c’est la base.

L’utilisateur a forcément tord dans 85% des cas voir plus (problème d’interface chaise-clavier responsable de 85% des plantages sans acte malveillant volontaires).



Après, pour les 15% restant, qui le font volontairement ou qui ont un problème lié à un bug du soft c’est autre chose…









the_Grim_Reaper a écrit :



Là, tu joue sur les mots, surtout que four chiffrer/crypterc’est grosso modo la même chose, par contre déchiffrer et décrypter sont différents de mémoire.





À vue de nez, crypter vient d’une déformation de l’anglais (encrypted) mais devient synonyme de chiffrer à force d’usage incorrect (de la même manière que “con” signifie désormais débile/idiot alors qu’il signifie vagin, à la base…). Je pense qu’il est en bonne place pour être officialisé mais les adeptes freineront toujours des quatre fers <img data-src=" />



Déchiffrer : rendre un message chiffré en clair en utilisant la clé qui a servi audit chiffrement

Décrypter : rendre en clair un message chiffré sans en avoir la clé



https://chiffrer.info&nbsp;<img data-src=">





Le chiffrage c’est un truc de chef de projet qui sert à tenter de

trouver combien de temps il faut pour coder mais sans la clé de

chiffrement. Ce qui fait que ça ne marche jamais.








Vekin a écrit :



Un avantage pour les utilisateurs, mais une galère pour les développeurs. Finalement, c’est pas si différent d’un changement d’OS, sachant que certains programmes peuvent être “cassés” ensuite.



Ça va être la joie dans les hotlines <img data-src=" />



“Vous utilisez quelle version de Windows ?”

“Windows 10”

“Oui, mais quelle update ?”

“Euh, j’en sais rien. C’est quoi une update ?”





Wééh! Encore une KaBbale de windows <img data-src=" />

(en plus elles sont numérotées)<img data-src=" />





<img data-src=" /> <img data-src=" />

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



très bon <img data-src=" />









chiffrer.info a écrit :



“En effet, la terminologie de cryptage reviendrait à coder un fichier sans en connaître la clé et donc sans pouvoir le décoder ensuite.”





ce qu’on appelle communément le “jet de pantoufle sur le clavier” (souvent utilisé pour créer un mot de passe, qu’on ne notera d’ailleurs pas - true story pour un compte paypal…) <img data-src=" />









127.0.0.1 a écrit :



Le principal problème de “Secure Boot” tel qu’il est implémenté, c’est qu’il veut bien faire confiance aux grandes entreprises (constructeurs, éditeurs) mais qu’il exclut totalement de faire confiance à l’utilisateur.



On le voit ici. Même si un utilisateur accorde sa confiance a VeraCrypt, l’utilisateur n’a aucun moyen d’ajouter VeraCrypt dans la chaine de confiance existante.



C’est une sorte d’UAC où seule une poignée d’entreprises ont le droit d’appuyer sur le bouton “toujours faire confiance a ce programme”.







D’après ce que j’ai compris, dans le fils de discussion de cette news, il y a moyen pour l’utilisateur d’autoriser lui même ses programmes. Bon, c’est vachement technique et pas forcément accessible au premier pécore venu, comme généralement ce qui tout touche à la sécurité.







WereWindle a écrit :



À vue de nez, crypter vient d’une déformation de l’anglais (encrypted) mais devient synonyme de chiffrer à force d’usage incorrect (de la même manière que “con” signifie désormais débile/idiot alors qu’il signifie vagin, à la base…). Je pense qu’il est en bonne place pour être officialisé mais les adeptes freineront toujours des quatre fers <img data-src=" />



Déchiffrer : rendre un message chiffré en clair en utilisant la clé qui a servi audit chiffrement

Décrypter : rendre en clair un message chiffré sans en avoir la clé





J’ai mis un lien vers une vidéo de linguisticae, mais en gros il faut distinguer plusieurs choses :




  • l’usage : la façon dont chacun utilise la langue

  • La norme objective “descriptive” : décrit l’usage et les règles qui en découlent

  • La norme subjective “prescriptive” : décrit le “bel” usage de la langue.



    Le problème est que la norme subjective n’est réellement utilisée que par un sous ensemble de la population, généralement l’élite, voir pas personne tellement elle est archaïque. Ainsi, l’utiliser fait de toi une élite, et sert du coup pas mal pour marcher sur la gueule des autres.



    (sinon, dans le même genre que con, tu as hystérique qui ne devrait s’appliquer qu’aux femmes)



Parfait je te remercie!


<img data-src=" />








tazvld a écrit :



Bon, c’est vachement technique et pas forcément accessible au premier pécore venu, comme généralement ce qui tout touche à la sécurité.







<img data-src=" />



Quand Ms veut faire simple, il sait faire.



Autoriser une appli a s’exécuter avec les droits admin: 1 clic

Autoriser une appli a accéder au réseau via le firewall: 1 clic

Autoriser l’exécution d’une appli téléchargée depuis internet: 1 clic

Accepter/Bannir les emails d’un expéditeur inconnu : 1 clic

Conserver/Supprimer un fichier détectée comme dangereux par l’anti-virus: 1 clic

etc.









the_Grim_Reaper a écrit :



Là, tu joue sur les mots, surtout que four chiffrer/crypterc’est grosso modo la même chose, par contre déchiffrer et décrypter sont différents de mémoire.



Crypter peut avoir 2 définition :

-aller dans une crypte ou un truc du genre (ce qui n’a pas vraiment d’intérêt ici <img data-src=" />)

-chiffrer sans connaître la clé de chiffrement ou en prenant une clé au hasard sans savoir laquelle. Tu conviendras avec moi qu’il y a plus de chance de voir une visite ET que de trouver une utilisation réelle à un “cryptage”… Vu que de toute facon il faudra décrypter pour décoder, étant donné que le déchiffrement simple sera impossible.







Otiel a écrit :



https://chiffrer.info <img data-src=">



<img data-src=" />









WereWindle a écrit :



très bon <img data-src=" />





ce qu’on appelle communément le “jet de pantoufle sur le clavier” (souvent utilisé pour créer un mot de passe, qu’on ne notera d’ailleurs pas - true story pour un compte paypal…) <img data-src=" />



Ce cryptage de l’enfer… <img data-src=" />



Heu… attention, secure boot n’est pas lié à windows, mais à l’UEFI et son consortium(AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft, et Phoenix Technologies pour les “Promoter” et plein d’autre personnes dont la fondation linux dans les contributeurs).



Là a priori, c’est plutôt la validation des drivers qui pose problème, chose que MS faisait déjà depuis très longtemps (j’ai eu des problèmes pour une carte d’acquisition TV-TNT avec Vista dès lors que j’avais plus de 2Go de RAM) mais qui semble imposer des drivers signés si le secure boot est activé (enfin, c’est ce que je comprend). Bon, à l’époque, je galérais pas mal pour lui faire accepter le pilote non valide.








Otiel a écrit :



https://chiffrer.info <img data-src=">







Très bon, je le garde sous le coude. Y’a pas le même pour digital Vs numérique ?



Bien tenté, mais de parle bien de “l’implémentation de SecureBoot par Microsoft” qui ne permet pas à l’utilisateur de modifier la whitelist/blacklist des exécutables UEFI afin d’autoriser/interdire ce qu’il considère comme bien/pas-bien.


Tel que je comprends le secure boot, son rôle est d’assurer que rien d’anormal s’est exécuté entre le démarrage de la machine et celui de l’OS. En gros, il dit à l’OS “RAS, c’est bon, tu es sur une une zone sécurisé”.

Là, c’est ensuite Windows qui impose que les pilotes soient aussi signer si le secure boot est activé. Mais en gros, ce n’est lié au sécure boot que par la condition qui impose des pilotes valides lors que le secure boot est activé.

Je cite l’article :







Guénaël Pépin a écrit :



Depuis l’Anniversary Update, Windows 10 n’accepte plus que les pilotes signés par Microsoft si Secure Boot est actif.





Du coup, ici, ce n’est pas le secure boot qui pose problème, il à fait son boulot, il a garantie à l’OS que c’est clean pour se lancer, mais la chaîne de vérification de Windows qui s’exécute après la validation du secure boot elle même qui prend en compte l’état de ce dernier.



c’était assez embettant aussi l’utilisation de 3DsMax et son FLEX licencing,

en gros apres un systeme encryption, si t’install 3Ds, ça foire une partie du bootloader,

ce dernier te dit que le system a été compromis par une attaque type Evil Maid.

j’ai dû chercher longtemps pour comprendre; c’est le genre de truc à foutre dans la faq.




Tel que je comprends le secure boot, son rôle est d’assurer que rien d’anormal s’est exécuté entre le démarrage de la machine et celui de l’OS. En gros, il dit à l’OS “RAS, c’est bon, tu es sur une une zone sécurisé”.





Effectivement, tu comprends bien ce que Microsoft dit à propos de Secure boot.



Sauf que Secure boot ne devrait pas là pour assurer que tout se passe comme Microsoft le veut.



Secure boot devrait être là pour assurer que tout se passe comme l’utilisateur le veut.


c’est mal ?


Oui, d’après la discussion que j’avais mis le lien, il serait normalement possible que l’utilisateur puisse signer son propre OS et le faire reconnaitre par son UEFI comme valide. (c’est un peu technique la doc, mais c’est ce que j’ai compris)





Là, le pilote est validé dans “l’univers Windows” et non dans l’univers “UEFI/secure boot”, le secure boot n’est pas responsable de ce présent problème.



C’est Windows qui rejette le pilote, pas secure boot.


Ca te plairait d’avoir un firewall avec des règles non-modifiables choisies par Ms ? moi, non.








tazvld a écrit :



Oui, d’après la discussion que j’avais mis le lien, il serait normalement possible que l’utilisateur puisse signer son propre OS et le faire reconnaitre par son UEFI comme valide. (c’est un peu technique la doc, mais c’est ce que j’ai compris)



Là, le pilote est validé dans “l’univers Windows” et non dans l’univers “UEFI/secure boot”, le secure boot n’est pas responsable de ce présent problème.



C’est Windows qui rejette le pilote, pas secure boot.







UEFI/SecureBoot s’occupe uniquement d’autoriser (ou pas) l’exécution du bootloader. Une fois autorisé à s’exécuter, c’est la fin de la partie UEFI/SecureBoot. Tout ce qui va se passer ensuite dépend du bootloader.



En l’occurrence, le bootloader de windows 10 écrit par Microsoft ne permet pas à l’utilisateur de décider s’il autorise (ou pas) de charger un driver non-microsoft au démarrage de windows (BOOT_START). Seuls les driver signés par Microsoft sont autorisés.



Ensuite, une fois l’OS démarré, Microsoft ne permet pas à l’utilisateur de décider s’il autorise (ou pas) de charger un driver non-microsoft (SYSTEM_START). Seuls les driver signés par Microsoft sont autorisés.



D’où les deux problèmes:




  1. l’installation du pilote par l’utilisateur (depuis l’interface graphique de Windows)

  2. l’exécution du pilote par le bootloader (lors du boot)



    Le problème 1 a été résolu… en demandant a Microsoft de signer le pilote pour permettre son installation.

    Le problème 2 n’est pas vraiment réglé, comme le dit la news: “Car pour chiffrer, le chargeur de démarrage (bootloader) du logiciel doit aussi être signé par Microsoft pour que Secure Boot le laisse se lancer. ”





    (a corriger par les experts si je me suis trompé quelque-part)



On est d’accord, ce n’est pas le secure boot qui est en cause ici. Si j’ai bien compris le post que j’ai mis en lien, l’utilisateur est libre d’ajouter un OS qu’il a lui même signé dans le secure boot.

Ici, c’est la partie de validation de la suite de la séquence de boot par Windows (ou de son bootloader) qui est en cause, séquence qui est en aval du secure boot.



Ce n’est pas un problème du secure boot, mais un problème lié à Windows.

Secure boot aurait (je reste au conditionnel au vu de mon niveau de compréhension de la doc technique) une option permettant de faire confiance à l’utilisateur.


Effectivement, en théorie secureboot pourrait permettre à l’utilisateur de modifier la bdd des certificats afin d’autoriser/interdire l’exécution du bootloader d’un éditeur quelconque.



En pratique la bbd est initialisée par le constructeur et pas toujours modifiable (meme si, heureusement, secureboot est souvent désactivable). Et concrètement le seul certificat dans la bdd est celui de Microsoft. <img data-src=" />





The Secure Boot database is initialized with a list of trusted signers at the Original Equipment Manufacturer’s (OEM) factory that identifies entities trusted to sign Option ROMs, bootloaders, drivers and applications. Instead of requiring a unique certificate from every possible trusted company, a centralized Certificate Authority (CA) is used.



Microsoft announced a program that allows industry companies to submit binaries for signing by a Microsoft UEFI CA. The certificate for this CA is provided to OEMs for inclusion at the factory. As use of Secure Boot expands into various new segments, additional CAs may be established to serve these environments.



source: http://www.uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Com…








127.0.0.1 a écrit :



Ca te plairait d’avoir un firewall avec des règles non-modifiables choisies par Ms ? moi, non.





euh là tu parles d’autre chose.

moi je parlais de ton post sur le&nbsp; “1-click” ici

je trouve ça bien.

&nbsp;

sous linux faudrait faire un doctorat en iptable pour autoriser une appli <img data-src=" />



Oui, mais là encore ce n’est pas le problème ici.



Bon, sinon dans ce que tu me racontes, j’ai l’impression que l’on nous refait le bordel du Bios et tout les systèmes de sécurité que les fabricants ajoutaient (à une époque certain PC portables empêchaient l’installation d’un autre OS que Windows), et là encore, ce n’est pas la faute du secure boot, mais bien des mecs qui l’implémentent un peu à leur sauces. Bon, je suis un peu mauvaise fois, et effectivement, la dessus, c’est permis car les spécifications ne semblent pas l’interdire, du coup, c’est aussi un défaut de spéficitications.



Sinon, oui, MS est le seul à délivrer des certificats car c’est le seul qui le fait, mais théoriquement, n’importe quel “promotor” de l’UEFI pourrait aussi le faire, cependant dans la pratique, c’est trop de contrainte pour rien au final (en gros, tu paies pour installer un coffre fort chez toi, vérifié régulièrement mais en retour tu ne peut t’attendre qu’à recevoir 3 cacahouètes sans la bière). Bon, là encore, c’est un défaut du système, difficile de faire un système décentralisé sûr (même une blockchain n’est pas sûr de tenir face à un gouvernement), et être l’un des centres, c’est cher pour aucune rétribution.





Sinon, je suis assez surpris, je ne sais pas trop comment fonctionne la DB, mais il me semble que MS n’est pas le seul à avoir un certificat valide, Redhat, Fedora , Ubuntu, SUZE et même la linux fondation en ont chacun un.


Putain, j’ai passé une journée complète à lire la doc de la crontab… A coté MS tu as le planificateur de tâches : même ma mère saurait l’utiliser. Et niveau fonctionnalité, ça surpasse la crontab, il n’y a pas que l’heure comme trigger possibles, mais plein d’événements qui peuvent être multiples pour une tâche.


ah désolé. J’avais mal interprété ton “c’est mal ?”. <img data-src=" />








tazvld a écrit :



Oui, mais là encore ce n’est pas le problème ici.







Bah, heu si. Le problème cité dans la news c’est la nécessité pour un éditeur tiers (VeraCrypt) de faire signer par Microsoft le driver qu’il a écrit afin qu’il s’installe sur Windows 10 AU, et le faire signer une seconde fois par Microsoft pour que le driver se charge lorsque Windows 10 AU démarre en mode secureboot.





Bon, sinon dans ce que tu me racontes, j’ai l’impression que l’on nous refait le bordel du Bios et tout les systèmes de sécurité que les fabricants ajoutaient (à une époque certain PC portables empêchaient l’installation d’un autre OS que Windows), et là encore, ce n’est pas la faute du secure boot, mais bien des mecs qui l’implémentent un peu à leur sauces. Bon, je suis un peu mauvaise fois, et effectivement, la dessus, c’est permis car les spécifications ne semblent pas l’interdire, du coup, c’est aussi un défaut de spéficitications.





Ce que je raconte c’est que SecureBoot a été vendu comme permettant de garantir à l’utilisateur que le bootloader n’a pas été altéré par un malware.



En pratique, Microsoft s’en sert pour garantir à l’utilisateur que seuls les drivers/services dument autorisés par Microsoft peuvent s’executer. Sauf que l’utilisateur n’a jamais demandé à Microsoft de se limiter à une whitelist écrite par Microsoft .





Sinon, je suis assez surpris, je ne sais pas trop comment fonctionne la DB, mais il me semble que MS n’est pas le seul à avoir un certificat valide, Redhat, Fedora , Ubuntu, SUZE et même la linux fondation en ont chacun un.





Si tu lis l’article de ton lien, tu verras que ce n’est pas le cas.



Microsoft a simplement signé avec sa propre clé le bootloader “shim” écrit par Canonical. Ce bootloader, nettement plus configurable que celui de windows, permet ensuite de lancer l’OS de son choix, en l’occurrence linux.



&nbsp;moi les “Linuxiens” quand je leur parle, limite ils voudraient que je fasse de l’infographie en CLI.

j’essaie de leur expliquer c’est quoi l’intérêt de l’ergonomie et la simplicité pour les gens normaux,

mais ça veut pas passer.



mais bon, si c’était trop simple il n’y aurait plu de Job pour les SysAdmin&nbsp; <img data-src=" />


Des “problèmes”, Vera Crypt résout des “PROBLÈMES”, pas des soucis.


Heu… crontab c’est super simple.

Et il existe des interfaces graphiques, si tu trouve ça quand même trop complexe.


personne n’a réagi alors jme permet de te dire que j’ai bien aimé ;)








Bamaury a écrit :



personne n’a réagi alors jme permet de te dire que j’ai bien aimé ;)





Je sais pas si tu fais bien de t’en vanter <img data-src=" />









Bamaury a écrit :



personne n’a réagi alors jme permet de te dire que j’ai bien aimé ;)





j’ai évité de relever parce ça m’a rappelé que ce film a 22 ans <img data-src=" />