Android 6 : Les nouveautés

Confirmer l'identité de l'utilisateur

Testez gratuitement nos 1300 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Vérifiez que l'utilisateur présent est bien le propriétaire du téléphone à l'aide de son code de déverrouillage du téléphone.
07:48

Transcription

Nous allons voir comment il est possible d'utiliser de nouvelles fonctionnalités liées au cryptage, qui ont été ajoutées dans Android 6, pour vérifier que c'est bien l'utilisateur principal du téléphone qui est en train de s'en servir. Qu'est-ce que ça veut dire ? Ça veut dire que pour les gens qui ont un téléphone avec une forme de vérouillage soit par code pin, par empreinte digitale ou par méthode de glissement. Vous allez pouvoir vérifier que c'est bien la même personne qui est là depuis que le téléphone a été déverrouillé. Si, il a été déverrouillé depuis trop longtemps vous avez besoin de vérifier, car vous avez des informations confidentielles à afficher, que c'est bien cette personne qui est là. Et donc, vous allez pouvoir exploiter ceci. Il y a beaucoup de codes pour arriver à ce résultat. Plutôt que de les coder en direct et de passer beaucoup de temps à taper du code. Je l'ai déjà codé et je vais vous l'expliquer. On va voir les points essentiels dont vous avez besoin et comprendre pourquoi c'est intéressant de le faire de cette façon-là. Voici quelques constantes que nous allons utiliser. On a le nom de la clé de cryptage. Pourquoi va-t-on utiliser une clé de cryptage ? En fait le système que l'on veut utiliser n'a pas été prévu à la base pour juste vérifier l'utilisateur actuel. Il a été prévu pour vérifier l'utilisateur actuel dans le cas où vous avez besoin d'encrypter des informations. Pour arriver à s'en servir on va être obligé d'encrypter des informations, même si dans notre contexte les données qu'on encrypte ne sont pas très importantes, puisque ce sont ces données-là. c'est un tableau avec des chiffres allant de un à six, mais c'est en encryptant cela, qu'on va pouvoir exploiter cette fonctionnalité de vérification de l'utilisateur actuel. On aura une clé pour le cryptage, des données à encrypter. Et ensuite, ce qui m'intéresse le plus ce sont ces trois parties-là. À savoir, comme toute à l'heure pour la gestion des permissions, quand on va demander de confirmer l'utilisateur, il nous faudra un REQUEST_CODE, ça c'est assez standard. Ceci, ça m'intéresse beaucoup c'est ce qui va me permettre de garantir la durée d'authentification. C'est à dire qu'une fois que la personne a rentré son code, et a déverrouillé son écran, en cinq secondes, je pourrai garantir que c'est lui. Au-delà, il faudra qu'il rentre encore une fois ces informations-là. Toutes les cinq secondes, je vais vouloir vérifier que c'est à nouveau lui pour faire des tâches on va dire « critiques ». Le KeyguardManager, ça va être l'objet qui va me permettre de gérer tout ceci. Alors cinq secondes pour la durée de validité c'est très court mais là, c'est volontairement pour débugger. On peut mettre par exemple dix secondes. Il faudra sur une application réaliste mettre une durée beaucoup plus longue pour éviter d'avoir à rentrer son code toutes les dix secondes Mais pour nous c'est intéressant, d'arriver à le mettre en place pour voir la perte d'autorisation au bout de dix secondes. Alors, ce KeyguardManager c'est un service système. Vous voyez il suffit de le demander. Nous on le fait dans le onCreate. On récupère cet objet KeyguardManager. Par contre, pour que tout ceci soit soit utilisable, il faut que ce soit un téléphone sécurisé. Ca veut dire, soit un code, soit un code de glissement, soit une empreinte digitale, quelque chose qui vérrouille ce téléphone au niveau de l'écran. Si, il n'y a aucune sécurité vous ne pourrez pas utiliser ceci. C'est pour ça, qu'après avoir récupéré le KeyguardManager, je vérifie bien qu'on est dans le contexte sécurisé avant de créer une clé de chiffrement. La création de la clé de chiffrement, on est ici. On a pas mal de codes pour créer une clé de chiffrement, c'est standard lorsque l'on a besoin de faire des cryptages. Moi, ce qui m'intéresse ça va être cette partie-là. Et ce sont ces deux fonctions-là qui ont été ajouté sur l'API 23. Tout le reste, ça existait déjà mais sur Android 6, ce qui a été ajouté c'est ceci et c'est ce qui m'intéresse le plus. À savoir, pour pouvoir utiliser cette clé et crypter quelque chose avec, je vais devoir avoir mon utilisateur qui sera authentifié. Je vérifie que c'est l'utilisateur qui a déverrouiller l'écran et en plus de ça, je vais pouvoir fixer une durée de validité pour cette authentification. Donc au-delà des 5, 10 ou 30 secondes, tout dépend du nombre qu'on aura mis dans cette constante, il va déconnecter l'utilisateur. La prochaine fois qu'on voudra générer quelque chose avec cette clé on se retrouvera dans le même contexte. Il devra encore une fois s'authentifier. Ce sont ces deux fonctions-là qui ont été ajoutées. Tout le reste, ça existait déjà. C'est grâce à ça, qu'on peut faire des choses intéressantes. Une fois que notre clé a été créé, nous pouvons nous en servir pour encrypter des données et vérifier que c'est l'utilisateur qui est toujours présent. Nous on le fait au moment de l'achat dans l'application puisque lorsqu'on affiche un item en détail on a un bouton d'Achat. Lorsque l'on appuie sur ce bouton, on revient sur l'activité principale avec le RESULT_OK, Ok pour dire « ok je vais l'ajouter ». Au lieu de l'ajouter dans le panier et de faire l'achat, c'est ici qu'on vérifie si c'est bien sécurisé. Si ce n'est pas sécurisé, j'affiche un message à l'utilisateur lui indiquant qu'il faut qu'il vérrouille son téléphone pour pouvoir faire des achats. Si non, j'essaie d'encrypter les données comme je vous disais. Cette fonction marque une tâche encore une fois elle va utiliser le keyStore comme toute à l'heure pour essayer d'encrypter quelque chose. On va récupérer la clé qu'on a créée juste avant pour encrypter et qui est liée à l'utilisateur qui est connecté. Et on va essayer d'encrypter nos données. c'est ici qu'on encrypte ce SECRET_BYTE_ARRAY, en essayant justement via la clé liée à l'utilisateur d'encrypter ses données. Si, il y a un problème, ou que ça ne marche pas car l'utilisateur est déconnecté ou autre. J'arrive ici. C'est un try catch. Si, il ne peut pas encrypter car l'utilisateur n'est pas connecté. On ne va pas continuer ces lignes-là. On n'arrivera jamais à cette fonction purchaseSucceeded. On va arriver ici dans UserNotAuthenticatedException. Soit l'utilisateur est authentifié, j'avance et je fais mon achat comme si de rien n'était. J'ai vérifié la présence de l'utilisateur, je fais mon achat. Si non, j'arrive ici. Je vais utiliser une fonction liée au KeyguardManager qui me permet de créer un Intent de connexion. Je vais pouvoir grâce à ceci, avoir un Intent tout prêt qui va me préparer une activité qui est liée à la méthode que l'utilisateur a choisie pour sécuriser son téléphone que ce soit un code pin, un glissement, une empreinte. Une fois que j'ai cet Intent je lance l'affichage de ceci pour vérifier que c'est bien lui. Vous me direz que l'on aurait pu l'utiliser dès le départ. C'est aussi simple et plus facile que le cryptage. Oui, c'est vrai mais on aurait dû à chaque fois relancer ceci alors qu'avec le système de cryptage on a automatiquement l'expiration au bout d'un certain nombre de secondes. Là, on n' aurait pas pû savoir depuis combien de temps ou il aurait fallu gérer l'expiration. À vous de voir ce qui est le plus intéressant. gérer tout un système de délai et d'expiration avant de réafficher cet écran-là ou alors utiliser ce système de cryptage qui, c'est vrai ajoute des lignes de codes mais n'est pas si compliqué que ça à mettre en place. On va lancer l'application pour vérifier que tout fonctionne. Je vais essayer de faire un achat. Si j'achète, là il me dit que mon appareil n'est pas sécurisé. Il faut aller dans Paramètres, Sécurité et Verrouillage. On le fait, on ajoute un code sur notre téléphone. Je vais dans Paramètres, Sécurité, Vérouillage de l'écran. On va ajouter un code pin 1234. Je confirme. Je fais donc 1111 comme mon code pin. OK. Maintenant que j'ai mon code pin qui a été réglé pour mon téléphone je vais pouvoir relancer l'application et essayer de faire un achat. J'arrive ici. Et lorsque je me connecte, il me demande le code pin 1111. Achat confirmé. Si j'essaie d'en faire un autre dans les dix secondes. Achat confirmé. Si j'attends plus de dix secondes, au bout d'un moment, il va expirer. Si j'essaie à nouveau de faire un achat, il me redemande le code. Ça a bien marché. Si je fais ANNULER, Achat annulé !, on voit qu'il n'a pas fait l'achat puisque je n'ai pas réussi à m'authentifier. Voilà, c'est un système intéressant qui vous permettra d'avoir une notion de vérification de l'utilisateur et une expiration de cette vérification.

Android 6 : Les nouveautés

Prenez en main les améliorations apportées à Android 6. Voyez l’introduction d’un système d'autorisations pour les applications, la sauvegarde automatique des données, etc.

1h04 (14 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Android Android 6
Spécial abonnés
Date de parution :13 sept. 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !