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
Le 19 août 2016 à 09h30
4 min
Logiciel
Logiciel
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.
Secure Boot : VeraCrypt 1.18a résout des soucis avec l’Anniversary Update de Windows 10
-
L'Anniversary Update plus stricte sur la signature des pilotes
-
VeraCrypt 1.18a toujours peu compatible avec Secure Boot
Commentaires (54)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 22/08/2016 à 12h45
Le 19/08/2016 à 09h34
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 19/08/2016 à 09h42
Les deux étant des mécanismes de protection différents pour des cas d’attaques différents, dans l’absolu, je dirais que oui.
Le 19/08/2016 à 10h00
Ç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.
Le 19/08/2016 à 10h01
On a le même problème avec Dokan :( GitHubNous allons faire la demande de signature chez Microsoft en espérant que cela va
prendre 2hr comme eu…
" />" />" />
Le 19/08/2016 à 10h03
" />
Le 19/08/2016 à 15h21
c’est mal ?
Le 19/08/2016 à 15h29
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.
Le 19/08/2016 à 15h30
Ca te plairait d’avoir un firewall avec des règles non-modifiables choisies par Ms ? moi, non.
Le 19/08/2016 à 16h01
Le 19/08/2016 à 16h17
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.
Le 19/08/2016 à 16h59
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. " />
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…
Le 19/08/2016 à 17h03
Le 19/08/2016 à 17h37
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.
Le 19/08/2016 à 17h51
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.
Le 19/08/2016 à 17h51
ah désolé. J’avais mal interprété ton “c’est mal ?”. " />
Le 19/08/2016 à 18h11
Le 19/08/2016 à 18h28
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 " />
Le 19/08/2016 à 18h47
Des “problèmes”, Vera Crypt résout des “PROBLÈMES”, pas des soucis.
Le 19/08/2016 à 22h26
Heu… crontab c’est super simple.
Et il existe des interfaces graphiques, si tu trouve ça quand même trop complexe.
Le 22/08/2016 à 08h38
personne n’a réagi alors jme permet de te dire que j’ai bien aimé ;)
Le 22/08/2016 à 11h02
Le 19/08/2016 à 12h58
Le 19/08/2016 à 13h10
Le 19/08/2016 à 13h26
https://chiffrer.info ">
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.
Le 19/08/2016 à 13h51
Le 19/08/2016 à 13h58
très bon " />
Le 19/08/2016 à 14h14
Le 19/08/2016 à 14h15
Parfait je te remercie!
Le 19/08/2016 à 14h18
" />
Le 19/08/2016 à 14h22
Le 19/08/2016 à 14h30
Le 19/08/2016 à 14h34
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.
Le 19/08/2016 à 14h43
Le 19/08/2016 à 14h44
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.
Le 19/08/2016 à 15h04
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 :
Le 19/08/2016 à 15h07
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.
Le 19/08/2016 à 15h12
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.
Le 19/08/2016 à 10h04
Le 19/08/2016 à 10h05
Pendant ce temps à Vera Crypt…
Le 19/08/2016 à 10h19
Le 19/08/2016 à 10h31
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 " /> )
Le 19/08/2016 à 10h37
@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…
Le 19/08/2016 à 10h44
Le 19/08/2016 à 10h50
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.
Le 19/08/2016 à 10h55
En fait il y a peut être un nouveau truc Je vais valider les contrats pour voir:
http://hpics.li/73ba21f
Le 19/08/2016 à 11h08
Le 19/08/2016 à 11h26
Pour ceux que ca intéresse:
Microsoft
Le 19/08/2016 à 11h35
Merci pour le lien !
>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 " />
Le 19/08/2016 à 11h51
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
Le 19/08/2016 à 12h07
Le 19/08/2016 à 12h10
Rien à foutre
Le 19/08/2016 à 12h24
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”.
Le 19/08/2016 à 12h33
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.