Powered By Blogger

Rechercher sur ce blogue

vendredi 29 octobre 2021

13 SERVEURS RACINES POUR INTERNET, POURQUOI PAS PLUS ?

 

 

 

13 SERVEURS RACINES POUR INTERNET, POURQUOI PAS PLUS ?










La version PDF de cet article est disponible sur ce lien


Rassurez-vous ce n’est pas parce que je suis né un 13. Il y a  plusieurs raisons qui ont poussé à la standardisation du nombre de serveurs racines (13) de l’Internet.
A travers cet article je  vous donnerai un aperçu sur cette passive problématique en mettant l’accent  sur les enjeux géo-stratégiques et politiques de la localisation et de l’administration de ces serveurs racines.
Avant l’entame du vif du sujet je voudrais vous présenter un petit aperçu sur le DNS, sur ce qu'est un serveur racine DNS (en anglais root server). Il ne faut déjà pas se faire une imagination particulière sur les serveurs racines. Ce sont des serveurs DNS (Comme nous pouvons l’installer sur nos machines ou en entreprise : Bind, NSD, Knot, Ect) et dont l’infrastructure (hardware) est bien dimensionnée (puissance de processeur, mémoire disque, etc.) et capable de répondre à la charge des requêtes DNS de l’Internet mondial.
De façon spécifique un serveur racine répond  aux requêtes  relatives aux noms de domaine de premier niveau (Top Level Domain TLD). Ils assurent donc la redirection vers les serveurs DNS de premier niveau demandé. Par exemple si  la requête envoyée vers le serveur racine concerne le domaine biaou.net, le serveur racine redirigera la requête vers le serveur DNS du .NET qui est enregistré dans sa base de données.
Le rôle des serveurs racines DNS est donc ultra important dans le fonctionnement de l’Internet aujourd’hui. C’est son point d’entrée.
Le Système de nom de domaine (DNS: Domain Name System), est construit, juste parce que nous, les humains ne sommes pas assez capables de nous souvenir des numéros (Adresses IP), ou il est plus facile pour l’humain de se rappeler plus les noms plutôt que les chiffres.
Ce système appelé DNS permet donc de réaliser cette association entre les noms et les numéros IP à notre place. On parle de résolution DNS.
Je vous recommande les lectures/Vidéos suivantes pour comprendre comment fonctionne le DNS (Vidéo Ici / Lecture).
Vu la criticité que représente l’Internet, il est important d’assurer sa robustesse, sa disponibilité et surtout sa résilience. Les concepteurs ont donc adopté une architecture hiérarchique pour le DNS et dont le sommet est la racine (.).
Image 1: Architecture Hiérarchique du DNS

Même si on parle souvent de “la racine” du DNS, Il est important de préciser qu’il existe 13 serveurs racines/instances pour Internet qui sont nommées de A à M. et gérées par 12 organismes différents.

Serveur racine Nom
Géré par
a.root-servers.net
j.root-servers.net
b.root-servers.net
c.root-servers.net
d.root-servers.net
e.root-servers.net
f.root-servers.net
g.root-servers.net
h.root-servers.net
L'armée américaine
i.root-servers.net
k.root-servers.net
l.root-servers.net
m.root-servers.net
WIDE

Pourquoi se limiter à 13 serveurs/Instances vu l’importance et la criticité de l’Internet aujourd’hui ?

Ce serait une belle blague technique de dire qu’il existe seulement 13 serveurs physiques pour la racine DNS de l’Internet. Nous avons 13 instances représentées chacune par une IP de la racine. Et derrière chaque instance plusieurs serveurs racines. Imaginez un instant que nous ayons un seul serveur racine, si cette unique racine du DNS a un problème,  l'ensemble de l'Internet sera affecté. Dans la suite de ce article je vous expliquerai pourquoi nous avons seulement 13 adresses IP pour la racine du DNS et pas plus.
Comme je l’ai dit plus haut nous avons 13 adresses IP. Si vous êtes familiers avec les réseaux informatiques ou si vous êtes un administrateur système, vous auriez certainement déjà entendu parler de ces deux protocoles: UDP (User Datagramme Protocol) et TCP (Transmission Control Protocol). Pour des raisons de performances et de rapidité,  le protocole UDP est très privilégié par rapport au protocole TCP particulièrement dans le DNS.
En effet, historiquement, le protocole UDP est généralement utilisé pour le DNS lorsque la taille des paquets DNS est inférieure à 512 octets. Dès que la taille passe à plus 512 octets c’est le protocole TCP qui est engagé. Le protocole TCP convient mieux pour la fiabilité et l’UDP est adapté à la performance.
Vu l’importance du DNS dans le fonctionnement de l’Internet, cette technologie ne devrait jamais être lente. Par conséquent le protocole UDP est celui qui convient pour assurer une bonne performance du DNS.
Un paquet DNS doit contenir toutes ces 13 adresses IP de la racine  de l’Internet et d'autres informations de protocole UDP.
§  Un paquet DNS a  une taille 512 octets (Historiquement)
§  Et 32 octets pour l’IP
Si les 13 adresses IP de la racine doivent être encapsulées dans un paquet DNS ils occuperont 416 (13 x 32) octets. Il restera donc 96 (512 - 416) octets pour les informations de l’en-tête du paquet UDP et éventuellement pour ajouter une autre adresse IP à la racine au besoin.
Il n’est pas compliqué que IANA (Internet Assigned Numbers Authority) définisse plusieurs adresses IP : 50 ou 100 pour la racine du DNS. Le problème c’est qu’on ne serait plus en mesure de les encapsuler tous dans un paquet DNS et par conséquent impossible de les envoyer dans un seul paquet DNS en UDP.
Dans un tel contexte on serait obligé de les envoyer en plusieurs paquets; ce qui réduira les performances, une exigence capitale pour le DNS car c’est le protocole TCP qui sera utilisé.
Cette contrainte a donc conduit à garder à 13 le nombre d’adresse IP pour la racine. Ce choix technologique est ainsi basé sur une contrainte de protocole Internet (IP) version 4 (IPv4) et celui de l’UDP.
J’imagine que vous avez maintenant une grande visibilité sur le choix du nombre 13 qui n’est pas aléatoire.
Maintenant avec l'apparition de l’IPv6 qui est codé sur 128 bits que va-t-il se passer?

Maintenant avec IPv6, aurions-nous moins de 13 adresses IP pour la racine DNS ?

Une adresse IPv6 est codée sur 128 bits. Alors il serait impossible d’ajouter les adresses IPv6 de la racine dans un paquet UDP. Déjà si on conserve les 13 adresses IPv4 il ne reste plus 96 octets sur 512 octets.
Mais ne vous inquiétez pas, l'arrivée de l’IPv6 qui est codée sur un nombre important de bit  a été anticipée au niveau du DNS. En 1999 une RFC: RFC 2671 (Mis à jour dans le RFC 6891) a supprimé la contrainte liée à la limitation de la taille des paquets DNS 512 octets. Désormais les paquets DNS peuvent atteindre 4096 octets et même plus. On parle donc depuis ce temps de l’introduction de l’EDNS0 extension du protocole Domain Name System (En anglais Extension mechanisms for DNS).
La standardisation de L’EDNS0 n’est pas seulement liée à l’IPv6. Elle est importante pour la mise en œuvre du DNSSEC dont je vous parlerai très bientôt dans une autre publication. Malheureusement plus de dix ans après la publication de cette RFC certains pare-feu sont toujours mal configurés et filtrent encore les paquets DNS de plus de 512 octets. Cela est un véritable danger pour la résolution des noms.
Pire, certains fournisseurs d’accès à Internet en France filtrent toujours et n’appliquent pas l’EDNS0 dans leur infrastructure. Je me suis amusé à vérifier cela via la boxe Internet de quelques opérateurs en France. Le constat est ultra amer et très décevant. Certains opérateurs filtrent toujours des paquets de plus 512 octets sur certains de leur firewall. Seul un opérateur a un pare-feu qui limite la taille du paquet à 1433 octets (Lors de mes tests).
Vous pouvez vérifier cela par vous-même et savoir si le pare-feu de votre fournisseur d’accès à internet filtre ou non les paquets DNS supérieur à 512 octets.
Si vous êtes sur une machine Linux/Mac OS
# dig +short rs.dns-oarc.net txt
Si la taille est inférieure à 2048 octets, danger : Les réponses aux requêtes DNS signées en DNSSEC c’est-à-dire sécurisées, auront du mal à traverser ces pare-feu; ce qui pourrait engendrer des problèmes au site web sécurisé en DNSSEC.
Il est important de retenir que cette limite est une très vielle pratique qui ne devrait plus être d’actualité surtout qu’aujourd’hui  six (06) des treize (13) serveurs racines sont en IPv6 et la racine signée en DNSSEC.

Combien de serveurs racines physiques avons-nous précisément?

J’espère que vous n’imaginez pas que nous ayons seulement 13 serveurs racines physiques.
Nous avons environ 370 serveurs racines physiques qui sont géographiquement distribués sur l’ensemble de la planète. Juste que l’ensemble de ces serveurs est accessible via les 13 adresses IP des différentes instances.
La répartition géographique des serveurs DNS est très importante. Elle permettra à un utilisateur localisé en France par exemple d’atteindre plus rapidement le serveur DNS racine près de chez lui que d'atteindre un serveur racine situé aux États-Unis.
C’est vrai qu’au début ils étaient tous situés aux États-Unis. Mais des améliorations récentes ont rendu disponibles dans différents pays et continents, des images de serveurs racines, démocratisant ainsi un tout petit peu l’impérialisme étasunien sur les serveurs DNS racines.

Comment ça marchent 13 IP racines pour plus de
370 serveurs racines physiques?

Il y a plusieurs serveurs pour une instance de serveur racine. Par exemple a.root-servers.net est une instance constituée de nombreux serveurs à différents endroits de la planète.
Il y une technique en réseau appelée Anycast. En effet, l’Anycast joue un rôle majeur dans la réalisation de cette architecture pour distribuer des serveurs racines DNS.
En termes simples l’Anycast est une technologie qui permet à plusieurs serveurs situés à des endroits différents de partager une seule adresse IP.  Avec l’Anycast, lorsqu'une requête est envoyée à une adresse IP racine, celle-ci sera redirigée vers  le serveur racine le plus proche ou le "plus efficace" en tenant compte de la métrique de routage.
Cela signifie que si je veux atteindre f.root-servers.net de Nancy, les emplacements les plus proches possibles sont Paris, Francfort en Allemagne et Genève en Suisse. Ça ne sera donc pas les Etats-Unis. C’est la raison pour laquelle les IP des serveurs racines sont des IP de type Anycast.
La racine DNS s’appuie  fortement sur cette technologie qui offre de nombreux avantages notamment une haute vitesse, une faible latence, une forte résilience aux pannes et une protection contre les attaques de types DDOS.

D’accord, mais comment sont-ils distribués
géographiquement sur la terre?

Selon Wikipedia, il y a plus de 370 serveurs racines réparties dans différents continents. La carte ci-dessous montre l’emplacement des serveurs racines DNS sur la planète.
On se rend compte qu’il existe plusieurs serveurs racines sur chaque continent.
Source : Root-Servers 
Image 2: Répartition Géographique des serveurs racines

Quel est le rôle des États-Unis aujourd’hui qui disposent un nombre important de serveurs racines sur leur territoire?

Les États-Unis dominent-ils Internet aujourd’hui?
Comme vous pouvez le déduire, la racine du DNS est à la fois le cœur et le maillon le plus important de l’Internet. Sur les 13 Instances de serveurs racines du DNS, 10 sont gérées par des organismes étasuniens  sous contrat avec leur Etat. Un serveur est géré par un organisme suédois, un autre par un organisme japonnais et puis le dernier par le registre européen basé aux Pays-bas (RIPE NCC).
Même si les États-Unis n’ont pas un contrôle absolu sur la racine du DNS il faut dire qu’ils ont aujourd’hui une position extrêmement dominante qui pourrait influencer l’Internet mondial.
D’ailleurs cette position étasunienne ne va pas durée.  L’Agence nationale des télécommunications et de l’information des États-Unis (National Telecommunications and Information Administration (NTIA) a annoncé le 14 Mars 2014 une ouverture importante qui pourrait changer  la donne par rapport à l’impérialisme étasunien sur la racine du DNS et sur l’attribution et la gestion des ressources critiques de l’Internet. Son intention est  le retrait et le transfert du rôle de la supervision de la fonction IANA (Internet Assigned Numbers Authority) à la communauté multi-partite mondiale de l’Internet
En effet, l’IANA qui depuis 1998 est une composante de l’ICANN a pour rôle la gestion de la racine du DNS, de l’attribution des adresses IP, et de la maintenance des protocoles du système Internet avec I'IETF.
Par ailleurs il est important de préciser en lisant dans les lignes de cette déclaration que le gouvernement  étasunien ne ferait pas cette concession sans aucune garantie de la continuité de la supervision de l’Internet. Aujourd’hui c‘est l’ICANN,  soumis au droit Californien, qui conduit ce processus de transition.  Vous pouvez suivre l’évolution des discussions publiques et de cette transition en consultant ce lien.

La version PDF de cet article est disponible sur ce lien
Références de rédaction

§  Ressource Wikipédia sur les serveurs Racines
 
http://fr.wikipedia.org/wiki/Serveur_racine_du_DNS


§  Serveurs Racines, Infrastructure critique de l’Internet par Sarath Pillai
http://www.slashroot.in/dns-root-servers-most-critical-infrastructure-internet

§  Explication du nombre de serveur par Miek GIEBEN
http://miek.nl/posts/2013/Nov/10/13%20DNS%20root%20servers/



§  Votre serveur DNS peut-il faire passer des paquets de toutes les tailles ? par Stéphane Bortzmeyer
http://www.bortzmeyer.org/dns-size.html
    §  Article de l’Afnic sur le rôle des Etats-Unis dans ICANN, par Pierre Bonis

     §  Wikipédia sur EDNS, IPv4, IPv6
         §  Processus de Transition de la fonction IANA par ICANN

https://www.icann.org/fr/system/files/files/process-next-steps-18jun14-fr.pdf

 

REF.:

lundi 25 octobre 2021

Le FBI s’attaque à la bête noire des secrets industriels Apple

 

 

Le FBI s’attaque à la bête noire des secrets industriels Apple

Les hackers de l’institution sont considérés comme parmi les plus efficaces de la planète.


Par iPhon.fr


En avril dernier, un groupe de pirates ciblait un sous-traitant d’Apple avec pour conséquence la révélation du design des nouveaux MacBook Pro sortis lundi dernier. Ce sont en effet grâce aux schémas mis en ligne lors de l’incident que l’absence de Touch Bar avait été évoquée avant son officialisation, tout comme le retour de la recharge MagSafe, du port pour carte SD et de la sortie HDMI.

Aux manettes de ce vol de données, REvil, qui profite de ses exactions pour demander une rançon à ses victimes. Ce qui n’est pas sans conséquence : plusieurs corps armés des États-Unis ont décidé de répliquer. Parmi eux, on retrouve notamment Cyber Command, chargé de la sécurité de l’information pour le Pentagone. À cette opération se sont aussi joints le FBI et les services secrets.

Des victimes ?

Objectif pour cette coalition : faire tomber le site web de REvil, en accédant directement à ses serveurs. Une initiative qui n’a pas manqué de fonctionner, portant alors un coup d’arrêt significatif aux activités de ces acteurs malveillants. Comme le rapporte l’agence de presse Reuters, il s’agit là d’une réponse notamment motivée par les récents déboires de Kaseya. Le développeur de logiciels pour entreprises avait été visé sérieusement pas les black hats en juillet dernier, compromettant alors nombre de ses dossiers.

Impossible de savoir si les autorités en ont profité pour interpeller des criminels, mais un membre de REvil a annoncé avoir été ciblé personnellement tandis qu’un autre a tout bonnement disparu. Rappelons que dans ce genre de cas, il n’est en fait pas rare de voir la justice les obliger à choisir entre peines de prison et retournement de veste. La seconde option étant généralement opérée dans le plus grand secret pour permettre aux pirates de rejoindre le département de la Défense et de lutter contre leurs anciens partenaires.

Bien se protéger en entreprise

On ne le répètera jamais assez : disposer d’une barrière efficace contre les virus, chevaux de Troie et autres ransomwares est indispensable à l’heure où les failles zero-day sont devenues un modèle de revenu à part entière. Sur Mac, les solutions de protection qui détectent les logiciels malveillants sont nombreuses et se différencient principalement par leur prix et les fonctionnalités proposées.

 

REF.:

Le Relais privé iCloud continue d’exposer l’adresse IP

 

 

Le Relais privé iCloud continue d’exposer l’adresse IP

Cette fonctionnalité n’est pour le moment disponible que pour certains utilisateurs payants.

Par

iPhon.fr

Le mois dernier, une nouvelle fonctionnalité d’iOS 15 dédiée à la confidentialité, le Relais privé iCloud, faisait parler d’elle. Et pour cause : censée cacher l’adresse IP de l’utilisateur, cette option la révélait en fait à de potentiels pirates. Or, alors qu’on aurait pu estimer Apple capable de résoudre cet incident à temps, un chercheur en cybersécurité du nom de Sergey Mostsevenko vient de découvrir que ce n’est pas le cas.

Mieux : selon l’analyste, le moyen qu’il a pu trouver pour lire les coordonnées des abonnés à ce service payant est en réalité différent de celui mis au jour en août. Le système d’exploitation propriétaire macOS Big Sur ne semble toutefois pas concerné, avec une vulnérabilité qui ne toucherait que les mobiles tels que les iPhone 13.

Quel danger pour les victimes éventuelles ?

Si votre adresse IP venait effectivement à fuiter de cette manière, un hacker pourrait alors en profiter pour vous géolocaliser avec une certaine précision. Qui plus est, il lui serait possible d’identifier votre fournisseur d’accès à internet (comme Bouygues Télécom ou Orange). Votre nom, vos fichiers ou encore vos identifiants, en revanche, ne devraient pas être exposés.

Le Relais privé iCloud est une fonctionnalité payante qui n’est accessible qu’en souscrivant à un forfait iCloud+. Cet abonnement est disponible avec trois capacités de stockage au choix :

  • 50 Go
  • 200 Go
  • 2 To

En plus du Relais privé iCloud, l’offre donne accès à un nom de domaine personnalisé pour son adresse e-mail et la prise en charge de vidéo sécurisée HomeKit pour cinq caméras. Il est aussi possible de partager le  service avec plusieurs membres de sa famille, comme pour Apple Music.

Alternative

Dans un récent billet de blog, Mostsevenko explique comment se prémunir de cette faille du Réseau privé iCloud. La première solution consiste, tout logiquement, à passer par un autre VPN (notre comparatif). Ceci déviera votre adresse IP vers d’autres serveurs, rendant son identification plus difficile et bien moins accessible au premier venu.

Désactiver JavaScript (JS) depuis les paramètres de Safari permettra aussi de bloquer l’interface WebRTC incriminée dans cette brèche, mais ceci risque de rendre la navigation plus compliquée tant les sites web en JS sont nombreux.

Il n’y a donc plus qu’à attendre un correctif de la part d’Apple, prévenue du problème.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

 

Relais privé : Apple ne vous aidera pas à contourner les géoblocages

Apple donne quelques détails sur le fonctionnement de Private Relay, son concurrent des VPN. Il indique également que cette fonctionnalité ne pourra pas être utilisée pour contourner les restrictions géographiques sur certains services en ligne.


Publié le 
 

 

Chaque année, Apple présente de nouvelles fonctionnalités pour aider ses utilisateurs à protéger leurs vies privées. Par exemple, lors de la WWDC 2020, la firme a annoncé l’ATT, la fonctionnalité d’iOS qui peut empêcher les développeurs d’applications de vous pister. Et lors de sa conférence de 2021, la firme a annoncé iCloud+.

iCloud+ est une nouvelle offre pour les clients du stockage payant d’iCloud qui inclut une série de fonctionnalités de protection de la vie privée. Et parmi ces fonctionnalités, il y a Private Relay ou relais privé.

 

Cette fonctionnalité, qui est toujours en beta, fonctionne plus ou moins comme un VPN (mais n’en est pas un), puisqu’elle vous permettra de sécuriser vos connexions et de cacher votre adresse IP. Pour le moment, on ne sait pas quand cette nouveauté sera disponible sur iOS 15. Mais en attendant, Apple publie un document qui nous donne quelques détails sur le fonctionnement de Private Relay.

Dans ce document, la firme réexplique l’utilité de cette protection. « Normalement, lorsqu’un utilisateur navigue sur le Web, les informations de base relatives à son trafic Web, telles que son adresse IP et ses enregistrements DNS, peuvent être consultées par les fournisseurs de réseau et les sites Web qu’ils visitent », lit-on. « Ces informations peuvent être utilisées pour déterminer l’identité de l’utilisateur et créer un profil de son emplacement et de son historique de navigation au fil du temps. Un utilisateur peut alors être ciblé par des publicités et des campagnes marketing indésirables, ou voir ses données combinées avec des données supplémentaires et vendues à d’autres sociétés. »

Et c’est contre cette collecte de données que les utilisateurs d’iCloud+ seront protégés. Private Relay chiffre les connexions qui ne sont pas encore chiffrées, et fait passer le trafic par deux relais. L’objectif est qu’aucune entité ne puisse combiner des données sur l’utilisateur lorsque celui-ci se connecte à internet.

Une protection, avec quelques limites par rapport aux VPN

Dans son document, Apple évoque aussi les limitations de son relais privé. La firme précise que la fonctionnalité protège l’identité des utilisateurs, tout en maintenant des informations de géolocalisation suffisamment précises pour prendre en charge les expériences personnalisées sur le web. Et par ailleurs, contrairement à certains VPN, cette fonctionnalité ne vous permettra pas de contourner les restrictions géographiques sur certains services.

Autre limitation : la protection de Private Relay ne s’applique pas aux services cellulaires le service de messagerie multimédia (MMS), les services de téléphonie (XCAP), etc.

De plus, Apple ne veut pas interférer avec les réseaux d’entreprises. « La plupart des paramètres réseau gérés utilisés par les entreprises ont priorité sur Private Relay. Si un appareil est équipé d’un VPN, que ce soit pour des raisons professionnelles ou personnelles, le trafic qui passe par le VPN n’utilisera pas Private Relay. De même, une configuration de proxy, telle qu’un proxy global, sera utilisée à la place de Private Relay », indique la firme de Cupertino.

 https://www.iphon.fr/post/private-relay-apple-ne-vous-aidera-pas-a-contourner-les-geoblocages

REF.:

Comment déverrouiller un téléphone si on a oublié le code

 

 

Comment déverrouiller un téléphone si on a oublié le code

 

Vous avez oublié le code ou le schéma de déverrouillage de votre mobile et il est complètement bloqué ? Selon la version d'Android, vous pouvez le débloquer ou vous devrez le réinitialiser à l'état d'usine pour en retrouver l'usage.

Indépendamment du code PIN associé à la carte SIM, Android propose plusieurs solutions de verrouillage pour protéger l'accès à un appareil mobile, et plus particulièrement aux données personnelles qu'il contient. Des solutions qui se mettent en place généralement lors de configuration initiale, mais qu'il est aussi tout à fait possible d'activer ou de modifier après. Sur les modèles récents, vous pouvez généralement utiliser une solution biométrique (lecture d'empreinte digitale ou reconnaissance faciale avec la caméra selfie). Mais sur tous les modèles, anciens comme nouveaux, vous pouvez définir un code numérique (code PIN) ou un schéma de verrouillage (un tracé pour relier des points sur l'écran).  

Malheureusement, si vous oubliez ce code ou ce schéma de déverrouillage, et si vous n'avez défini aucune alternative biométrique, vous mobile se bloque et vous n'avez plus accès à rien ! Logique puisqu'il s'agit d'une mesure de sécurité destinée à interdire l'utilisation de votre téléphone ou de votre tablette par un inconnu, en cas de vol notamment. Rassurez-vous, il existe des solutions pour débloquer votre appareil. Mais la méthode et, surtout, le résultat varient selon la version d'Android. 

En effet, Google a renforcé la sécurité d'Android à chaque nouvelle version en complexifiant et même en supprimant totalement les options permettant de contourner un code ou un schéma de déverrouillage oublié. Ainsi, si vous avez un vieux mobile, vous pourrez facilement le débloquer sans rien perdre. Mais si vous utilisez un modèle récent, vous n'aurez pas d'autre solution que de le réinitialiser en effaçant tout son contenu…    

Comment déverrouiller un téléphone bloqué sous Android 4.4 ou inférieur ?

Si vous avez un vieil appareil fonctionnant sous une ancienne version d'Android (4.4 ou antérieure), vous pouvez facilement le débloquer quand vous avez oublié le code ou le schéma de déverrouillage.


  • Sur l"écran de déverrouillage, saisissez cinq fois de suite un code ou un schéma (n'importe lequel !). Une alerte s'affiche signalant que vous avez tenté de déverrouiller l'appareil avec un mauvais code ou un schéma incorrect. L'écran est alors bloqué pendant trente secondes.
  • Passé ce délai, une nouvelle option s'affiche. Appuyez sur Code oublié ? ou Schéma oublié ? selon le cas. Un écran de connexion à votre compte Google associé à l'appareil apparaît. Saisissez l'adresse e-mail du compte et le mot de passe. Votre smartphone est en principe déverrouillé.
  • Retournez ensuite dans les paramètres de votre mobile pour y configurer un nouveau code ou un nouveau schéma de verrouillage. Et essayez de ne pas l'oublier cette fois !

Comment déverrouiller un téléphone bloqué sous Android 5.0 ou supérieur ?

Depuis Android 5.0, Google a drastiquement renforcé la sécurité en supprimant notamment la possibilité de réinitialiser un code ou un schéma de déverrouillage oublié. Si vous avez bloqué votre smartphone, vous n'avez pas d'autre solution que de le réinitialiser complètement pour le remettre à l'état d'usine, avec tous les paramètres par défaut, comme au premier jour. La manipulation peut être réalisée de deux manières : la première en utilisant le service Localiser mon appareil qui permet d'effacer un mobile à distance, la seconde, en accédant au menu de réinitialisation caché d'Android accessible à l'aide d'une petite manipulation.

Avec le service de localisation

  • La manipulation ne peut évidemment pas se faire avec votre appareil bloqué ! Prenez un ordinateur, une tablette ou un autre téléphone, lancez un navigateur Web, puis allez sur le service Localiser mon appareil et connectez-vous à même compte Google-que celui utilisé sur votre appareil bloqué.

  • Votre mobile bloqué est automatiquement localisé. Cliquez alors sur Erase Device (Effacer l'appareil) et confirmer la suppression des données de l'appareil en cliquant sur le bouton Erase Device.

  • Pour lancer le processus de réinitialisation de l'appareil dans ses paramètres d'usine, vous devez confirmer une dernière fois votre choix en saisissant le mot de passe de votre compte Google.

  • Appuyez ensuite sur Effacer dans la boîte de dialogue qui s'affiche pour valider la suppression définitive des données de votre appareil.

  • Pour l'utiliser à nouveau, vous devez reconfigurer votre appareil comme s'il était neuf, tout juste sorti de sa boîte.

Avec le menu de restauration

Votre mobile étant verrouillé par un code ou un schéma dont vous ne vous souvenez pas, vous ne pouvez pas évidemment le réinitialiser de façon normale, depuis les paramètres d'Android. Mais vous pouvez passer par un menu caché de restauration, accessible au démarrage via les boutons physiques de marche-arrêt (Power) et de volume.

  • Assurez-vous que la batterie de votre mobile est bien chargée puis éteignez votre mobile.
  • Appuyez ensuite simultanément sur le bouton de mise en marche (Power) et sur le bouton Volume + ou volume - (cela dépend de votre modèle). Le menu de démarrage d'Android – le bootloader, dans le jargon – s'affiche. Son apparence et les intitulés des options peuvent varier selon le constructeur de l'appareil, mais vous devriez facilement vous y retrouver, même si tout est en anglais.
  • Pour naviguer dans les menus, utilisez les boutons Volume + et Volume -. Allez ainsi sur l'option Recovery Mode qui passe en surbrillance. Pour valider votre sélection, appuyez sur le bouton Power.

  • Une fois dans le mode Recovery, allez jusqu'à l'option Wipe data/Factory Reset avec les boutons Volume + et Volume - validez avec le bouton Power.

  • Un message Wipe all user data s'affiche (généralement en rougen, car il est important). Choisissez Yes ou Factory Data Reset avec les boutons Volume + et Volume - validez avec le bouton Power.. En bas de l'écran, un message Data Wipe Complete s'affiche confirmant la réinitialisation du mobile.

  • Sélectionnez ensuite le menu Reboot system now à l'aide des boutons de volume, et validez avec le bouton Power. Votre mobile redémarre vierge de toute donnée, tel qu'il était à sa sortie d'usine. Il ne vous reste plus qu'à le reconfigurer entièrement, comme au premier jour. Vous pouvez toutefois gagner du temps en utilisant votre compte Google pour récupérer automatiquement des applications et de nombreuses données personnelles (contacts, agenda, etc.).

Comment déverrouiller un téléphone Samsung bloqué ?

Si vous utilisez un modèle Samsung et si vous avez configuré un compte Samsung, vous pouvez débloquer votre appareil avec le service en ligne Traçage du mobile, qui permet de gérer votre mobile à distance en cas de perte ou de vol mais aussi de le déverrouiller si vous avez oublié votre code. Attention toutefois, à partir d'Android 9, l'option Déverrouillage à distance doit avoir été activée au préalable dans les paramètres de l'appareil.

  • L'opération ne peut évidemment pas s'effectuer avec votre appareil bloqué ! Prenez un ordinateur, une tablette ou un autre téléphone, lancez un navigateur Web, puis allez sur le service Traçage du mobile de smartphone Samsung et connectez-vous à votre compte Samsung.

  • Une fois connecté, cliquez sur le bouton Déverrouiller mon appareil. Validez le déverrouillage de votre appareil en saisissant le mot de passe de votre compte Samsung pour confirmer que vous êtes bien le propriétaire de l'appareil. Cliquez ensuite sur le bouton Déverrouiller.
  • Votre mobile est débloqué et le code ou le schéma de verrouillage a été désactivé. Vous devrez donc retourner dans les réglages de votre smartphone pour configurer à nouveau le verrouillage à l'aide d'un code, d'un schéma, ou en utilisant le capteur d'empreinte ou la reconnaissance faciale, selon ce que propose votre appareil.

REF.: