Microsoft récupère vos clés de chiffrement. Voici comment les en empêcher"¦

Mauvaise nouvelle pour tous les Windowsiens... Si vous avez acheté un appareil sous Windows 10 équipé d'une puce qui chiffre par défaut le disque, ne vous pensez pas en sécurité pour autant : La clé de récupération qui vous permet de déchiffrer vos données en cas d'oubli de mot de passe, est envoyée sans votre consentement sur les serveurs de Microsoft et associée à votre compte Microsoft.

En effet, par défaut, sur les versions Pro ou Enterprise, la clé de déchiffrement est stockée sur les serveurs de Microsoft (OneDrive) ou sur le serveur Active Directory si celui-ci est disponible. Pour les versions Home, comme il n'y a pas d'Active Directory, ça part direct vers OneDrive. Cela veut dire que quiconque a accès à cette base de données chez Microsoft (un employé, un pirate, la NSA...etc.) peut ensuite déchiffrer les données qui se trouvent sur votre disque dur.

Je vous "rassure", ça part d'un bon sentiment pour permettre à madame Michue qui a perdu son mot de passe, de récupérer ses données en se connectant avec son compte Microsoft.

Mais vous le savez comme moi, l'enfer est pavé de ces bonnes intentions. Toutefois, il est possible de supprimer ces clés de déchiffrement des serveurs de Microsoft et d'en générer de nouvelles qui ne partiront pas sur les serveurs de Microsoft. Lancez une invite de commande MS DOS en tant qu'Administrateur et entrez les commandes suivantes :

On va d'abord suspendre le chiffrement BitLocker :

Puis on va supprimer la clé de récupération :

Et en recréer une nouvelle :

Pensez bien à la noter dans un coin, car celle-là ne sera uploadée nulle part...

Ensuite, réactivez BitLocker et le tour sera joué :

Vous pouvez vérifier que cette clé n'est pas uploadée à nouveau sur les serveurs de Microsoft, en vous rendant après votre prochain reboot sur ce site. Pensez aussi à supprimer les clés présentes sur le site s'il y en a.

http://korben.info/wp-content/uploads/2015/12/capture-de--cran-2015-12-31-08.30.52-650x172.pngSource

Voir l'article complet