Rupture de flux git à distance

Si vous stockez un secret sur git, vous êtes censé le stocker chiffré (évidemment).

Pour faire un versionnage, vous utilisez simplement un commit. Comme l’algorithme de chiffrement n’est pas déterministe (comme il se doit, ce n’est pas un hachage), vous vous retrouvez avec un blob de données chiffrées qui est entièrement différent du commit précédent. Il est impossible de faire une comparaison et le fichier complet est téléchargé à chaque fois.

Maintenant, plus drôle. Vous voulez faire une git merge car 2 branches ont reçu des mises à jour séparées sur leurs secrets. Comme vous devez comparer 2 fichiers chiffrés entièrement différents, quels avantages peuvent offrir toute stratégie merge de git. Vous finirez certainement par bousiller votre fichier et perdre les secrets qu’il contient.

Rupture de flux git local

Vous pourriez dire “de cette façon, je gère mes secrets avec le même flux que mon code”. Et je répondrai “Vraiment? En êtes-vous vraiment sûr?”

Jetons donc un œil à votre flux local, car je vous ai déjà expliqué que votre flux distant est définitivement mort.

• Vous tirez le repo
• Vous l’intégrez dans votre VSCode ou votre terminal ou tout autre IDE
• Vous changez quelque chose sur le code
• Vous commit
• Vous tirez et poussez

Ok, maintenant pour les secrets.

• Vous tirez le repo
• Vous l’intégrez dans votre VSCode ou votre terminal ou tout autre IDE
• Jusqu’ici tout va bien
• J’espère que vous avez installé l’outil pour déchiffrer votre fichier de secrets
• Vous le déchiffrez (en espérant que l’outil soit intégré dans votre IDE)
• Vous changez quelque chose dessus
• Vous le chiffrez avec le même outil ou un autre
• Vous vérifiez deux fois que vous n’avez pas laissé le fichier non chiffré quelque part sur votre espace de travail
• Vous commit avec une goutte sur le front et une douleur au ventre
• Vous tirez
• Vous essayez de comprendre comment résoudre le conflit entre vos 2 blobs de fichier chiffré car un nouveau commit à distance a déjà modifié le fichier
• Vous commit à nouveau en espérant que vous n’avez pas tout foiré
• Vous poussez
• Vous voyez par la suite que vous avez commit également le fichier non chiffré et que les secrets sont maintenant disponibles librement sur le remote
• Vous essayez désespérément de réinitialiser bousillant le flux git pour toute l’équipe
• Vous pleurez

Je ne suis pas sûr que ce soit le même flux git.

En conclusion, stockez vos secrets dans des stockages faits pour cela. Par exemple, Hashicorp Vault sur votre infrastructure et keepassXC localement.

Avec copier, on a tout en yml. Ce que je souhaite :

• pouvoir être DRY(Don’t repeat yourself)
• avoir un mécanisme d’héritage ou apparenté qui me permette d’appliquer plusieurs templates en même temps
• ça soit intégrable en CI avec immutabilité
• avoir la possibilité de créer des sous-templates (par exemple pour gérer les roles d’une collection ansible)

Du coup, j’ai conçu un petit script en python pour étendre copier en m’appuyant sur la doc de copy:

https://copier.readthedocs.io/en/stable/api/

Avec son système de sous-répertoires, on va faire nos diverses variations.

Organizing cookiecutters in directories (1.7+) - cookiecutter 1.7.2 documentation

Le problème avec cookiecutter c’est que pour l’instant il n’existe pas de méthodes pour générer une arborescence de dossiers à partir d’une liste.

Imaginons un repo ansible, on voudrais pouvoir définir des roles, et pour chacun des roles, on voudrait définir le dossier de tests molecule et le playbook de base qui va avec.

Du coup, on aurait une sorte de sous-template comme ça :

roles     ->role1
          ->role2
molecule  ->role1
          ->role2
playbooks ->role1
          ->role2

Donc, on voudrait générer ça à partir d’une liste:

{
  roles: [
    role1
    role2
  ]
}

On s’appuit sur l’idée de base ici :

Creating cookiecutter multiple sub-folders from template

mais il y a des trucs qui ne fonctionnent pas.

On doit se battre en plus avec le fait que cookiecutter a des fichiers de config en json et en yml.

Ça rend les choses compliquées (et instables) dés qu’on a des tableaux complexes.

Donc :

• renovate
• semantic-release

On va les coder simplement sans fioritures et on les refactorera une fois qu’on aura retrouvé tous nos outils de CI.

On va d’abord coder le role ansible container. Ce role aura la charge de faire toutes les tâches nécessaires à la création d’un container avec ansible.

C’est lui qui installe l’entrypoint ou les dossiers selon la XDGBase Directory Spec.

Il paramètre aussi l’ensemble des déclarations de l’image container résultante.

On cherche aussi à utiliser un inventaire en yml avec molecule au lieu du fichier hosts en INI.

Cela afin d’avoir une syntaxe semblable sur l’ensemble du projet.

Je voudrais automatiser la création de README selon un template et la création de la doc.

Pour cela, on va utiliser le paquet

kefranabg/readme-md-generator

et un template selon ce paquet pour générer automatiquement notre README.

Ce générateur en nodejs me pose quand même quelques soucis. Il n’est pas maintenu depuis 2 ans et est vraiment spécifique à nodejs.

Du coup, stand-by et on va réfléchir au truc.

la génération de doc pour shell semble se faire avec

https://github.com/reconquest/shdoc

sans problèmes.

Reste à tester

https://github.com/thegeeklab/ansible-doctor

et

https://www.npmjs.com/package/doctoc

Passons maintenant à la mise en place d’un environnement nodejs pour pouvoir restaurer les containers renovate et semantic-release.

C’est bon à l’exception de Gitlab qui met n’importe quoi comme nom de commit, comme d’habitude.

Le projet ansible-environments c’est la collection ansible qui fournit les environnements de base des langages sécurisés et paramétrés pour la prod.

Son pendant Inspec ce sont les profils Inspec chargés de tester ces environnements.

Nous avons aussi créé un projet qui centralise les artefacts nécessaires à tous les repos.

Ces artefacts sont en vrac :

• CONTRIBUTING.md
• LICENSE.md
• Des gitlab-ci.yml de lint et release
• Des presets de release
• Des presets de renovate

security.txt a été oublié, il faudra l’ajouter.

Pourquoi ?

Parce que je suis à peu près à 80 repos git actifs pour le projet de forge logicielle.

C’est trop, ça introduit des instabilités partout et une capacité de progression réduite (PR en attentes…)

Pourquoi je n’ai pas monorepoysé plus tôt ?

Parce que je crains le repo fourre-tout et les monorepos ont tendance à aller dans cette direction.

Du coup, on va réfléchir nos monorepos.

Je propose donc:

• monorepo services de la forge logicielle
• monorepo outils de la forge logicielle.
• monorepos cucumber et Inspec correspondants (donc 4 monorepos)

Les services de la forge logicielle sont les containers qui tournent en permanence (Gitea, Concourse-ci, etc…)

les outils de la forge logicielle sont les containers appellés pour résoudre une tâche (ansible, inspec, etc…)

Il y a un container qui fonctionne comme un service mais qui est un outil (plus une sorte de container side-car), c’est renovate. Donc lui, je vais le gérer dans le monorepo des outils.

Je passe donc mon temps à chercher des infos dans le code et faire divers tests pour trouver les paramètres que GoHarbor accepte.

Portal m’a fait ressurgir des limbes de mon cerveau la notion d’héritage de templates jinja2 au sein d’ansible.

Avec ça je peux modifier le template vhost de base de nginx avec une variante locale (spécifique à GoHarbor).

Dans le cadre des collections ansible, il peut être nécessaire d’installer les collections dans le projet lui-même en exécutant une commande du type :

ansible-galaxy collection install -r requirements.yml -p ./collections

Cela permet d’utiliser des chemins relatifs dans la déclaration extends des templates jinja2.

L’init passe si on n’oublie pas de paramétrer le répertoire container-init qui contient le fichier LOCK déclenchant le démarrage des autres containers.

Paramétrer veut dire le créer et lui affecter le USER du container init.

Maintenant, on débugge les valeurs manquantes dans les fichiers de config de GoHarbor.

GoHarbor a besoin de 3 interfaces publiques:

• celle de core qui gère l’accès à l’API REST
• celle de portal qui gère l’accès à l’interface web de gestion
• celle du registry qui gère les push et pull des images

Donc, on doit créer 3 noms domaines pour les tests:

• core.coppint.test
• web.coppint.test
• registry.coppint.test

Ces noms de domaines ont leur port définis sur 444, 443 et 445 depuis l’extérieur.

Playlist ambiance

 Artiste : Almusic34

Titre : 432 Hz Space ambiant

Lien : https://freemusicarchive.org/music/almusic34/single/432-hz-space-ambientmp3

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Almusic34

Titre : 432 Hz tuned Landscape 1

Lien : https://freemusicarchive.org/music/almusic34/single/432hz-tuned-landscape-1mp3

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Ov Moi Omm

Titre : And Their Domain

Lien : https://freemusicarchive.org/music/ov-moi-omm/single/and-their-domain

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Almusic34

Titre : Deep space travel

Lien : https://freemusicarchive.org/music/almusic34/single/deep-space-travelmp3

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Almusic34

Titre : Harmony in the night

Lien : https://freemusicarchive.org/music/almusic34/single/harmony-in-the-nightmp3

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Lex Villena

Titre : Origins

Lien : https://freemusicarchive.org/music/lex-villena/single/origins

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Almusic34

Titre : Peace landscape 3

Lien : https://freemusicarchive.org/music/almusic34/single/peace-landscape-3mp3

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Ov Moi Omm

Titre : Somewhere Above South Eastern Oceans

Lien : https://freemusicarchive.org/music/ov-moi-omm/single/somewhere-above-south-eastern-oceans

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Almusic34

Titre : Space ambiant mix4

Lien : https://freemusicarchive.org/music/almusic34/single/space-ambient-mix4mp3

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Ov Moi Omm

Titre : The Sabian Star Worshippers

Lien : https://freemusicarchive.org/music/ov-moi-omm/single/the-sabian-star-worshippers

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Almusic34

Titre : tranquility

Lien : https://freemusicarchive.org/music/almusic34/single/tranquilitymp3

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : Almusic34

Titre : Voices and bells

Lien : https://freemusicarchive.org/music/almusic34/single/voices-and-bellsmp3

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Playlist introduction

Artiste : Itsensäsyöjät

Titre : Introduction beats

Lien : https://freemusicarchive.org/music/Itsenssyjt/Elektrique/01-Introduction_beats

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Artiste : ROZKOL

Titre : Opening Credits

Lien : https://freemusicarchive.org/music/ROZKOL/Roadside_Picnic/ROZKOL_-_Roadside_Picnic_-_01_Opening_Credits

License : Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/

Playlist conclusion

Artiste : TRG Banks

Titre : Evening journey

Lien : https://freemusicarchive.org/music/TRG_Banks/The_Rainbows_End/Evening_journey

License : CC0 1.0 Universal (CC0 1.0) Public Domain Dedication https://creativecommons.org/publicdomain/zero/1.0/

Ancienne playlist

License: Creative Commons Attribution 4.0 International (CC BY 4.0)

• https://www.chilloutmedia.com/who-i-want-to-be
• https://incompetech.filmmusic.io/song/6928-on-hold-for-you
• https://incompetech.filmmusic.io/song/3454-bossa-antigua
• https://incompetech.filmmusic.io/song/4379-smooth-lovin
• https://incompetech.filmmusic.io/song/3918-inspired
• https://incompetech.filmmusic.io/song/3408-backbay-lounge
• https://freemusicarchive.org/music/BODYSURFER/Digital_Prints/17-17
• https://freemusicarchive.org/music/BODYSURFER/Digital_Prints/Call_Your_Grandma
• https://freemusicarchive.org/music/BODYSURFER/Digital_Prints/Jax-Trax
• https://freemusicarchive.org/music/BODYSURFER/Digital_Prints/Ready
• https://freemusicarchive.org/music/BODYSURFER/Digital_Prints/Wants_To_Know
• https://freemusicarchive.org/music/Andy_G_Cohen/prisma/hoist
• https://freemusicarchive.org/music/Andy_G_Cohen/prisma/our-young-guts
• https://freemusicarchive.org/music/Drake_Stafford/Turtle_Warnings/Weirder
• https://freemusicarchive.org/music/Drake_Stafford/Turtle_Warnings/Yodelling_Walmart_Kid
• https://freemusicarchive.org/music/Drake_Stafford/SUNDAY/ROLLA_-_DRAKE_STAFFORD
• https://freemusicarchive.org/music/Drake_Stafford/SUNDAY/CASETS_-_DRAKE_STAFFORD
• https://freemusicarchive.org/music/Drake_Stafford/SUNDAY/Dolos
• https://freemusicarchive.org/music/Drake_Stafford/SUNDAY/FADED_-_DRAKE_STAFFORD
• https://freemusicarchive.org/music/Drake_Stafford/Drake_Stafford_-_Singles/Devil_Man
• https://freemusicarchive.org/music/Drake_Stafford/Drake_Stafford_-_Singles/Glimpse_1485

License : Creative Commons Attribution 3.0 Unported (CC BY 3.0)

• https://escp-music.bandcamp.com/track/dreamwalking
• https://soundcloud.com/artificial-music/ythc?in=artificial-music/sets/waves
• https://soundcloud.com/artificial-music/tea
• https://soundcloud.com/jas-productionz/lo-fi-type-beat-she-so-cold-rap-hip-hop-beat
• https://soundcloud.com/jas-productionz/lo-fi-hip-hop-x-boom-bap-rap-type-beat-keeping-secrets
• https://soundcloud.com/thisislegang/it-meant-everything-to-me
• https://soundcloud.com/thisislegang/ill-go-out-to-run-now
• https://soundcloud.com/thisislegang/come-on-lets-go

Un doute m’assaille quand même sur la façon dont portal se connecte au backend.

En effet, il n’apparait nulle part, côté portal, de paramètres qui permette de déterminer l’uri des backends.

Du coup, on va tâtonner. On va faire le fichier docker-compose au mieux, le faire tourner et voir à quoi ressemble l’interface web (portal quoi !).

standalone-db-migrator a besoin de paramètres postgres pour se connecter à la DB et faire ses migrations. Il utilise les même paramètres que core dont SSL_MODE qu’on peut mettre à verify-full et ça c’est cool !!!!!

Du coup, il ne faut pas oublier de monter le couple clé/certificat TLS plus la chaîne de certification dans les répertoires client de postgres. Et ça fait du mTLS. En plus de celà, il faut extraire les fichiers SQL de migration et les monter dans le container init avec un bon POSTGRES_MIGRATION_SCRIPTS_PATH.

Jusqu’à présent, on utilisait le paramètre delegate_to pour accéder à l’environnement du container.

Maintenant, on va le déclarer dans l’inventaire et y accéder à partir de l’inventaire. L’inventaire sera divisé en 3 parties :

• la première construit le container de base et le provisionne avec l’environnement python nécessaire à ansible
• la deuxième partie provisionne le container en se servant de la déclaration du container dans l’inventaire (plus besoin de delegate_to)
• la troisième partie conclut le container. C’est à dire qu’il lui ajoute ses déclarations de containérisation (CMD, USER, …)

Vient la construction du docker-compose.yml. C’est celui qui contient le plus de containers au sein du projet de forge logicielle.

Quelques éléments :

• Le TLS se fait avec les variables d’environnement INTERNAL_TLS_ENABLED
• Le container registryctl a un point de montage commun avec le container registry qui contient le fichier de configuration de registry

Donc, on finit les tests Inspec avec un patch à merger :

nginx parsed config as attribute by micheelengronne · Pull Request #44 · dev-sec/nginx-baseline

Et on se replonge dans GoHarbor.

on va pouvoir ajouter Portal à la liste de nos containers GoHarbor en utilisant le role ansible nginx et en incorporant le code html extrait de la phase de compilation.

Portal se construit avec la task synchronize d’ansible qui a une syntaxe différente de copy pour pourvoir uploader le code html.

Le débuggage de cette étape au prochain épisode.

Il y a un problème à régler avec nginx en container. Quelle est la bonne architecture ?

Les tests seront de 2 types, internes et externes.

• Les tests internes vont vérifier la configuration de nginx.
• Les tests externes vont vérifier que nginx produit bien des pages web accessibles depuis l’extérieur.

On va formaliser ces tests avec :

inspec/inspec

Avec Inspec, les tests internes seront différenciés par le fait qu’ils seront exécutés dans l’environnement distant.

Pourquoi l’environnement distant ?

Parceque nous n’exécutons jamais Inspec au sein de l’environnement testé. Cela afin d’éviter des biais de test entre le dev, le staging et la prod.

Nos tests Inspec pour nginx sont basés sur :

dev-sec/nginx-baseline

J’ai donc créé un PR pour soft-coder l’emplacement des fichiers de configurations nginx. Cela permettra de rendre le profil compatible avec des installs qui utilisent la XDGBase Directory Specification :

softcoded nginx path by micheelengronne · Pull Request #43 · dev-sec/nginx-baseline

Pour la disposition des couples clé/certificat TLS et le certificat de la chaîne de confiance, je place tout ça dans $HOME/.ssl par analogie avec la disposition de ssh. Je nomme les fichiers selon le nom de domaine qu’ils signent. Le certificat de la chaîne est nommé root.crt en rappel de la façon de nommer chez Postgres.

La génération de Diffie-Helman est longue mais m’a donné une idée. Un service qui génère à l’avance du Diffie-Helman. Il en existe déjà un basé sur dhtools :

Public Diffie-Hellman Parameter Service/Tool

Donc un deuxième service serait pas mal (avec des fonctionnalités supplémentaires) ?

Pour celà on va modifier et mettre à jour un vieux profil Inspec et l’adapter aux nouvelles façons de concevoir le code.

La question est de savoir si il est pertinent d’installer nginx en container en respectant l’arborescence classique adaptée aux multi-users ou si il vaut mieux faire une arborescense mono-user selon les standards de containerisation.

On part donc sur une installation mono-user respectant la XDG_Base_Directory.

XDG Base Directory

Pour les paramètres qui changent au démarrage du service, on souhaite n’utiliser que des variables d’environnement, comme dans tous les containers.

Ça veut dire que dans le cas de nginx, on va se servir de perl :

Docker environment variables and NGINX

La subtilité du container portal c’est que le code est un package nodejs qui ne provient pas d’un repo mais est extrait localement depuis la phase de compilation.

Donc, on va devoir faire avec pour le moment.

Plus tard, quand un repo npm sera installé, on uploadera ce paquet dans le repo dans une phase préparatoire (depuis un projet à part) et on utilisera ce paquet correctement installé depuis le repo.

Pourquoi ?

Pour profiter du système de dépendances de npm et ainsi coder d’autres packages qui se greffent à celui-là.

Mais pour ce soir, on va faire simple.

Premier truc à modifier, c’est l’appel des images containers depuis le docker-hub. En effet, pour éviter de heurter l’API rate limiting, on va essayer de changer ces appels et les remplacer par nos propres images.

On va placer le code de portal dans le répertoire /home/goharbor/srv car nos containers ne tournent pas en root et sont mono USER donc le code doit se trouver dans le HOME de ce USER.

Pourquoi srv ?

Parce que le code de portal est considéré comme du code nécessaire à exécution du service au sein du container.

Pour ref:

Where should the web server root directory go in linux?

Pour bien faire les choses, on va créer un role dans la collection ansible qui configure les environnements de base.

Ce role paramétrera nginx de façon sécurisée et il sera utilisé pour portal.

Pour les tests bats, on va tester l’upload, le download et l’access control d’images dans le Docker registry.

Le problème c’est qu’on ne peut pas utiliser la commande Docker pour ça. Pourquoi ? Parceque dans DinD, le processus Docker est lié à l’host sous-jacent et donc on peut se retrouver à avoir des disparités et des instabilités dans les tests dus aux réglages différents des host.

À noter au propre, les schémas de DinD depuis Instagram.

podman ayant un output différent, il faut écrire les tests en fonction.

Finalement les tests bats sont passés, le merge est fait et les artefacts de prod réalisés (container init et container registry).

On va donc pouvoir faire les tests côté GoHarbor.

On va donc faire des suites de tests bats pour s’assurer que notre container (à notre sauce) faisant tourner le registre officiel fonctionne bien.

Les suites de tests sont :

• contrôle d’accès
• upload et download

C’est des suites de tests de base. la grande majorité des tests sera faite au niveau de GoHarbor.

On a besoin malgré tout d’un container init pour créer un fichier de configurations minimaliste dont se sert registry.

L’essentiel de la configuration peut être pourtant gérée avec des variables d’environnement.

Le registre peut aussi avoir redis greffé, c’est cool.

Finalement, on a pas beaucoup avancé mais on a appris des trucs.

On va d’abord revenir sur la gestion des configurations dans les containers GoHarbor.

En effet, hier, on avait déterminé 3 types de configurations :

• L’hyperstatique
• La statique
• La dynamique

Ces caractérisations sont superflues et on va simplifier ça avec la norme :

XDGBaseDirectorySpecification

Dans notre cas, nous allons gérer les templates de configuration au niveau du container init. Il aura la charge des les mettre dans les bons répertoires si il peut y accéder et si un fichier équivalent n’est pas déjà présent.

Après avoir essayé de compiler le registry officiel de docker, nous nous sommes rendu compte que la dernière release avait 2 ans et que sa façon de compiler avait changé.

Release registry 2.7.1 · docker/distribution

La mort dans l’âme, nous nous sommes résignés à utiliser un commit plutôt qu’un numéro de version pour assurer l’immutabilité et utiliser un code récent.

Merge pull request #3314 from crazy-max/dummy · docker/distribution@35f1369

Et la compilation a trés bien marché. On a un beau binaire registry qu’on va pouvoir mettre en container lundi.

En plus, on va faire un container à notre sauce avec le projet officiel de docker registry.

docker/distribution

Pourquoi ? Parceque Goharbor s’appuie sur le registre officiel de Docker en backend.

Il y a deux types de containers. Un qui gère des binaires et l’autre qui gère du nodejs.

Ces deux types ne faisant pas appel au même language de programmation et donc au même environnement, leurs configurations vars.yml doivent être différentes.

On va donc construire les containers binaires avec le role coppint.environment.binaries et le container nodejs avec le role coppint.environment.nodejs.

Le container harbor_core ne semble pas charger de configuration par défaut (ou il la charge silencieusement). Il faut donc trouver comment charger un fichier de configuration spécifique.

C’est semble-t-il le cas de l’ensemble des binaires. Cela semble être géré par des variables d’environnement. C’est plutôt cool dans un environnement conteneurisé !

Les fichiers de configurations au sein des containers sont de nature variée et donc doivent être gérés de façon différente.

Nous avons des fichiers de configuration hyperstatiques qui peuvent être gérés comme du code.

Nous avons des fichiers de configuration statiques qui peuvent être gérés par du templating ansible et sont valables pour la durée de vie du container-image.

Et nous avons des fichiers de configuration dynamiques qui sont gérés par dockerize au moment de l’initialisation du service.

Sur le plan des bases de données, GoHarbor n’a pas de base propre. Il utilise la base de données du projet docker/distribution.

Nous voulons uniquement ceux de Goharbor et pas des dépendances externes.

Les dépendances externes (Redis, nginx, postgres) ont ou auront leurs propres projets.

Premier travail de ce soir, déployer GoHarbor avec l’installer officiel pour déterminer quels containers sont créés et quels sont les fichiers de configuration générés.

On va donc tester ça dans un vagrant en local.

Le script nécessite sudo partout. C’est terrible dans un environnement de prod.

Bien sûr, ne pas oublier de faire tout ça dans un sous-répertoire de /vagrant sinon on perd tout au prochain vagrant destroy.

Après avoir générer les certificats TLS comme indiqué ici :

Harbor - Configure HTTPS Access to Harbor

et mis tout ça dans les bons répertoires, le script sudo ./prepare --with-notary --with-trivy --with-clair --with-chartmuseum semble fonctionner :

prepare base dir is set to /vagrant/harbor-test/harbor
Generated configuration file: /config/portal/nginx.conf
Generated configuration file: /config/log/logrotate.conf
Generated configuration file: /config/log/rsyslog_docker.conf
Generated configuration file: /config/nginx/nginx.conf
Generated configuration file: /config/core/env
Generated configuration file: /config/core/app.conf
Generated configuration file: /config/registry/config.yml
Generated configuration file: /config/registryctl/env
Generated configuration file: /config/registryctl/config.yml
Generated configuration file: /config/db/env
Generated configuration file: /config/jobservice/env
Generated configuration file: /config/jobservice/config.yml
loaded secret from file: /data/secret/keys/secretkey
Copying nginx configuration file for notary
Generated configuration file: /config/nginx/conf.d/notary.upstream.conf
Generated configuration file: /config/nginx/conf.d/notary.server.conf
Generated configuration file: /config/notary/server-config.postgres.json
Generated configuration file: /config/notary/server_env
loaded secret from file: /data/secret/keys/defaultalias
Generated configuration file: /config/notary/signer_env
Generated configuration file: /config/notary/signer-config.postgres.json
Generated configuration file: /config/clair/postgres_env
Generated configuration file: /config/clair/config.yaml
Generated configuration file: /config/clair/clair_env
Generated configuration file: /config/clair-adapter/env
Generated configuration file: /config/trivy-adapter/env
Generated configuration file: /config/chartserver/env
Generated configuration file: /compose_location/docker-compose.yml
Clean up the input dir

Du coup on tente l’install.

L’install est très instable mais elle donne un docker-compose.yml et une liste de containers et de configurations. Le but est de réduire le scope des containers propres à GoHarbor et d’évacuer les containers des services associés vers leurs propres projets (redis, postgres et éventuellement notary, clair, etc…).

En fouillant dans les projets officiels, je trouve des surprises. Notary, par exemple, n’a pas de release depuis quasiment 2 ans :

Publish a release · Issue #1583 · theupdateframework/notary

Pour chartmuseum, on est à quasiment 1 an :

Release ChartMuseum v0.12.0 · helm/chartmuseum

Kubernetes et donc Helm/Chart (vu qu’on veut faire du Gitops) ne sont pour le moment pas dans le scope du projet de forge logicielle, donc chartmuseum sera réévalué plus tard.

Au final, on a 3 binaires :

• harbor_core
• harbor_jobservice
• harbor_registryctl

Et un package nodejs : portal

On a deux helpers à compiler aussi :

• migrate-patch
• standalone-db-migrator

Du coup, la story va consister à créer les containers harbor_core, harbor_jobservice, harbor_registryctl, un container init (avec les migrate) et le container portal.

On va faire communiquer tout ça ensemble avec les containers officiels postgres, redis et nginx.

On va appliquer des features cucumber et un profil Inspec là-dessus.

Puis, dans un second temps, on va ajouter les scanners et notary.

Tout ça pour ce projet de forge logicielle.

Ce soir, on va démarrer la mise en containers de GoHarbor.

L’idée est de récupérer les binaires créés au sein du script d’install de GoHarbor.

Ensuite, on les installe à notre sauce :

• Container créé avec ansible
• Init scripts avec pre-hook et post-hook
• Pas de compilation au sein des containers
• Tests dynamiques créés avec Cucumber
• Tests statiques créés avec Inspec (CINC-auditor)
• renovate pour gérer les dépendances de façon immutable
• semantic-release pour gérer les releases (tags et artefacts)
• Un contributing standard
• Un dockerignore qui vide le contexte de Docker car on utilise ansible pour construire les containers
• Un gitlab-ci.yml temporaire, le temps qu’on migre vers concourse-ci
• Un test d’upgrade_path fait avec Cucumber
• Un prepare.sh qui génère les binaires et les transmet entre les étapes
• Un docker-compose d’exemple (autonome, sécurisé)
• Des environnements de dev locaux basés sur docker-compose et déclenchables à partir de VSCodium dont un déclencheur qui nettoie complètement l’environnement

Pour cela, il est nécessaire de réussir à compiler les binaires de Goharbor sans passer par une succession de containers Go afin d’extraire des binaires adaptés à notre OS (Ubuntu).

Dans un premier temps, on va faire du DinD (Docker in Docker) et utiliser leur flag de compilation tel quel, c’est à dire en appelant un container GO distant.

Mais ce n’est pas une solution durable car cela oblige à conserver Docker dans l’infrastructure ce qui est contraire à l’un des buts du projet global. On veut, en effet, se débarrasser de Docker au profit de podman/buildah.

Pour référence :

Compile binaries without docker · Issue #13885 · goharbor/harbor

Les dépendances externes seront traitées dans des projets séparés (Clair, Notary,…). Ceci afin d’augmenter la réutilisabilité des portions de l’infrastructure.

Notamment, les bases de données comme Redis ou PostgreSQL n’ont pas d’intérêt à être conçues uniquement pour l’usage de GoHarbor.

Kubernetes déclare que dans sa dernière version (la version 1.20) ils vont déprécier Docker.

Qu’est ce que ça veut dire ?

Est-ce que vous ne pourrez plus utiliser de conteneurs avec Kubernetes

Est-ce que vous allez devoir reconstruire tous vos conteneurs ?

Rassurez-vous, non.

Alors qu’est ce que c’est docker par rapport à Kubernetes et par rapport aux conteneurs ?

En fait, Docker c’est une appli extrêmement complexe qui certes fait de la conteneurisation mais elle veut aussi faire la gestion de réseau, gestion de volume et caetera… De la construction de conteneurs, les faire tourner et caetera…

Ça se voulait une solution absolument contexte. Ils avaient fait docker swarm par exemple. Ils se voulaient être un concurrent de Kubernetes.

Ou plutôt Kubernetes était un concurrent de Docker Swarm parceque si je me souviens bien, Swarm est sorti avant. Faut peut-être vérifier ça, je suis pas sûr.

Mais la conteneurisation en tant que tel, le fait de faire tourner des conteneurs, c’est pas spécifique à Docker. Ces couches de programmation, Docker, les a en commun avec tout un tas d’autres projets dont Podman (dont vous avez sûrement entendu parler si vous suivez la chaîne)

Et il y en a un autre qui s’appelle CRI-O et Kubernetes, lui, veut tendre tout vers CRI-O.

Alors comment ça se décompose ces couches de programmation ?

Tout d’abord, à la base on a Runc qui est compatible et qui est maintenu par l’Open Container Initiative, une association qui gère ça et Runc, par exemple pour concourse-CI, est le niveau le plus bas sur lequel il peut gérer des conteneurs.

Au dessus de Runc, du coup, on a une couche de programmation qu’on appelle containerd qui a été à la base conçu par les ingénieurs de chez Docker et qu’il a ensuite libéré. Alors je crois qu’ils l’ont envoyé à l’Open Container Initiative mais je suis pas sûr de ça. Mais quoi qu’il en soit, c’est maintenant commun à d’autres systèmes que Docker.

Et au dessus on a Kubernetes et Docker.

Kubernetes, jusqu’à présent, utilisait un outil qui s’appelle Docker-shim. Il était là pour faire la traduction entre Docker et Kubernetes.

Parce que Kubernetes ne gérait pas directement Docker. Il était obligé de passer par ce système parce que l’API de Docker était très touffue et différente de celle de Kubernetes.

Donc l’équipe de Kubernetes a dit :

“bon, on a 2 standards, runc et containerd pour faire tourner les containers. Maintenant, nous on a inventé Container Runtime Interface donc une interface pour pouvoir accéder à containerd et runc qui est beaucoup plus légère qu’on appelait CRI. Et l’implémentation, CRI-O. Alors, pourquoi on continue avec ce truc lourdingue qu’est Docker avec lequel on est obligé de passer par un truc qui s’appelle Docker-Shim qu’est instable et tout ? Pourquoi on passe pas tous directement sur CRI-O ?”

Ils ont pris la décision de tout passer sur CRI-O. Alors, il y a peut-être d’autres supports aussi que CRI-O.

Et donc normalement c’est beaucoup plus léger.

Ça veut dire quoi ?

Vos containers que vous avez construit avec Dockerfile ou avec d’autres systèmes qui prennent en compte Docker sont toujours compatibles.

Il y a peut-être des problèmes à la marge mais normalement ils sont toujours compatibles avec votre Kubernetes.

Donc ça ne va rien changer pour vous si votre coeur de métier c’est de faire des containers.

Ça va changer pour ceux qui veulent mettre en place du Kubernetes. Parce que là ils ne pourront plus utiliser Docker pour gérer les containers de leur infra Kubernetes.

Ils vont devoir passer par CRI-O mais il est beaucoup plus léger que Docker donc normalement ça devrait être beaucoup plus performant.

L’inconvénient, c’est que CRI-O, lui, ne peut pas construire de container. Il peut juste les faire tourner. En plus lui même, je crois, ne gère pas le réseau, tout ça c’est délégué à Kubernetes. Alors que Docker, lui, gérait du réseau.

Donc pour build, il faut toujours soit passer par Docker, soit passer par d’autres solutions comme Podman/Buildah (nous on veut tendre vers ça).

Et ensuite, une fois que le container est construit, on peut toujours le faire tourner sur Kubernetes avec CRI-O.

Donc, ne vous affolez pas, vos containers sont toujours compatibles avec Kubernetes même s’il ne tourneront plus avec Docker dans Kubernetes.

Voilà.

Chef publie des solutions de déploiement et tests d’infrastructure, dont Inspec, une solution de test système.

Chez Limawi, nous utilisons Inspec en version opensource pour tester l’état de nos systèmes.

Il y a un an, Chef a rendu ses binaires compilés propriétaires à partir du code source resté opensource. Pour ne pas être rendu dépendant de cette nouvelle licence, nous avons décidé de compiler notre propre Inspec.

Puis, nous avons migré vers cinc-auditor il y a quelques temps. Cinc-auditor est une compilation faite à partir du code source mais avec une licence opensource.

Pour l’instant cette solution dépend du code source d’Inspec. Ce n’est pas un fork.

De plus, Chef a été racheté par Progress. Des vagues de licenciement ont lieu en ce moment chez Chef.

Nous suivons donc de près cette affaire.

N’hésitez pas à suivre cinc sur Twitter.

Sources

• https://www.chef.io/
• https://github.com/inspec/inspec
• https://cinc.sh/start/auditor/
• https://twitter.com/quinnypig/status/1313678400419033089?s=28
• https://github.com/micheelengronne/inspec
• https://twitter.com/cincproject

Mise en place par DigitalOcean, il y a 7 ans.

Les participants gagnent un T-shirt s’ils ont 4 PR(«push request») réussies sur le mois d’octobre au sein de projets opensource hébergés sur Github.

Cette année, le challenge a dérapé (plus que les années précédentes). Un youtubeur, qui dispose d’ une large communauté, a montré comment gagner un T-shirt en employant une technique s’apparentant à du spam. Le tout ressemblant à de l’attaque DDOS sur les projets visés. Les mainteneurs ont été débordés de requête d’ajout de code sans intérêt. Les infrastructures de test ont fait tourner des instances inutilement.

DigitalOcean a décidé d’y remédier en ne validant que les PR sur projet ayant opt-in (en mettant le label Hacktoberfest sur le repo Github.). Github a créé la faculté d’interdire les PR provenant de comptes créés trop récemment.

Les spammers ont alors imaginé une solution. Ils ont créé des repos Github opensource automatiquement et ont créé des PR dedans qu’ils validaient eux-mêmes.

Nous sommes le 8 octobre et comme son nom l’indique cela va continuer tous le mois. D’autres surprises ne manqueront pas de venir.

N’hésitez pas à suivre le compte shitoberfest sur Twitter pour vous délecter des perles de code pourri et pleurer avec les mainteneurs.

Sources

• https://github.com/Stanford-BASES/Website/pulls
• https://github.com/android-police/androidpolice-public/pull/127
• https://github.com/narze/jubeat-memo-analyser/pull/1
• https://github.com/COVID19Tracking/website/pulls?q=is%3Apr+is%3Aclosed+label%3Aspam
• https://github.com/search?q=auto-hacktober&type=Repositories
• https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama
• https://twitter.com/shitoberfest

La méthode que nous utilisons est une dérivée de la méthode agile appelée « Scrum ». Cette méthode doit son nom aux réunions matinales de l’équipe comparées à une mêlée de rugby (« Scrum » signifie mêlée).

Comment ça marche ?

Concrètement, on détaille le projet en un ensemble de tâches (qu’on appelle histoires) et on étale ces histoires sur des périodes de temps qui se répètent (qu’on appelle « Sprint »).

L’idée est d’impliquer les clients du projet à intervalles réguliers en fonctionnant par itération.

Un Sprint passe, le client voit le travail accompli et décide de modifier des choses ou de continuer le projet, un autre Sprint se forme alors. Et ainsi de suite.

Une équipe agile comporte généralement moins de 7 personnes. Au-delà, l’équipe perd en efficacité.

Dans la série d’articles de ce dossier, vous verrez comment formaliser les histoires pour répondre aux besoins spécifiques du projet et du client et comment structurer vos Sprints pour les garder efficaces.

La méthode agile est souvent associée à des techniques DevOps (et DevSecOps, MarketOps…) dont nous parlerons dans un futur dossier.

On commence par quoi ?

Et bien, commençons par le début d’un projet, la phase de «  Discovery & Framing ».

Puis, je vous invite à lire les articles sur les histoires, la Cérémonie, le Backlog, le Scrum et le Sprint pour avoir une vue d’ensemble de cette méthode.

Ensuite, n’hésitez pas à explorer, les hyperliens ça sert à ça.

Le Product Owner

Le Product Owner est le représentant des clients et de leurs désirs. Il a en charge le bon déroulement du développement du produit, le résultat du projet.

Il ne participe pas au développement et ne fait pas partie de l’équipe agile car il doit rester neutre par rapport à l’esprit d’équipe qui se forme.

Il a la charge de prioriser les tâches au cours des cérémonies afin de conserver les objectifs. C’est le principal mainteneur du Backlog et du Lean Canvas.

Il est souvent assisté du Scrum Master.

Il a la décision ultime et il est le seul qui peut déplacer une histoire en DONE (à l’exception éventuelle de bots spécifiques à des NFR répétitifs comme les mises à jour).

Il est l’interface entre l’équipe et les autres acteurs du projet et bien sûr, les clients.

Les Product Owners peuvent se hiérarchiser entre eux avec un Product Manager gérant l’ensemble des équipes agiles d’un projet et le Backlog général. Dans ce cas, le Product Owner d’une équipe ne gère que les histoires du Backlog avec les labels dévolus à cette équipe.

Le Scrum Master

Le Scrum Master a en charge la bonne santé de l’équipe. Il est là pour s’assurer que l’équipe suit toujours la méthode agile « Scrum » et ses bonnes pratiques.

Au début, il anime les réunions quotidiennes «  Scrum » de l’équipe.

Il est au service de l’équipe et fait en sorte qu’elle se sente bien et reste efficace. Il cherche à lever les obstacles rencontrées par celle-ci.

Il veille à ce que l’équipe gagne en autonomie. C’est lui qui insuffle des pratiques nouvelles, si nécessaire, en accord avec le Product Owner.

Il n’est en aucun cas une sorte de chef d’équipe.

Des types d’équipe agile

Une équipe agile est constituée au maximum de 7 personnes. Au delà, l’efficacité de l’équipe diminue rapidement.

L’environnement des ces équipes sera plus détaillé dans un futur dossier. Mais voici un avant-goût.

MarketOps

L’équipe de marketing opérationnelle a la faculté de déterminer des stratégies marketing de court terme et de les mettre en place rapidement.

DevSecOps

Hérité du DevOps. Cette équipe développe, met en production (opérationnel) et sécurise ses développements.

Elle peut être parfois scindée en 2, une équipe étant dédiée à la réalisation des tests dans l’optique de diminuer les biais humains dus au fonctionnement en équipe.

Blue Team / Red Team

Pour des projets avec plus de moyens, on peut dédier deux équipes à la sécurité du projet (informatique ou autre).

La Red Team représente l’agression, l’attaque. Elle a pour charge de penser comme un agresseur éventuel et de chercher toutes les failles du projet pour le mettre à mal.

La Blue Team représente la défense. Elle doit défendre le projet des agressions et mettre en place les outils pour y parvenir.

Cette façon de faire permet de prévenir plutôt que guérir.

Les Sprints de ces équipes peuvent être organisés autour d’objectifs :

• Le CTF (Capture the Flag) consiste à récupérer une information au sein du système pour la Red Team et à l’empêcher pour la Blue Team ;
• L’arène de destruction consiste à détruire des portions du système pour la Red Team et à l’empêcher pour la Blue Team ;
• « Vous ne passerez pas ! » consiste à fermer des accès au système pour la Red Team et à les maintenir ouverts pour la Blue Team (utile pour les DDOS en informatique) ;

Sources

• L’expérience Limawi
• Scaled Agile Framework
• Savoir Agile

Le Backlog rassemble l’ensemble des histoires d’un projet. Cette liste est généralement numérique mais peut être présentée sous forme de postits.

Cette liste est maintenue par le Product Owner avec l’aide du Scrum Master.

Chaque histoire, au sein du Backlog a un label décrivant sa structure ( NFR, Story, Spike…) et des labels d’avancement et de portée. Tous les acteurs du projet peuvent ajouter des histoires au Backlog car il rassemble toutes les sources d’actions du projet (Bug Tracker, User Feedback, retour d’intégration continue, retour éventuel de logs, rapports d’erreurs, discussions entre acteurs…).

À chaque cérémonie, le Product Owner extrait du Backlog un certain nombre d’ histoires et leur spécifie un label d’avancement. Ces histoires extraites forment un sous-Backlog intitulé Sprint Backlog. Le Backlog général, dans ce cas, porte le nom de Product Backlog. Notez qu’on peut hiérarchiser des Backlogs comme on le souhaite afin d’affiner au mieux et de garder de l’efficacité.

Toutes les histoires du Sprint Backlog doivent être estimées par l’équipe et le Poker agile.

Le label de portée peut être défini par n’importe quel acteur du projet qui suit la stratégie de management du projet (membres de l’équipe ou uniquement le Scrum Master par exemple). Il définit aussi un sous-Backlog et permet de faire fonctionner plusieurs équipes en parallèle ou de diriger les histoires vers les membres de l’équipe qui peuvent y répondre le mieux.

Exemples de labels

Labels d’avancement utilisés chez Limawi :

• DISCUSSION : Cette histoire n’a pas encore été étudiée. C’est un nouveau retour d’une source, une nouvelle idée…
• TODO : Cette histoire a été estimée et extraite du Backlog par le Product Owner pour le Sprint backlog en cours. Elle n’a pas encore été commencée par l’équipe.
• DOING : Après TODO, une fois que l’équipe a commencé l’ histoire.
• REVIEW : Après DOING, une fois que l’équipe a estimé avoir fini l’ histoire. Un membre de l’équipe qui n’a pas participé dans cette histoire ou un membre extérieur estime si le développement effectué correspond bien à l’histoire. Il y a souvent un va-et-vient entre DOING et REVIEW pour affiner la correspondance entre l’ histoire et son développement.
• DONE : Après REVIEW, une fois que la personne en charge de la revue a donné un feu vert. L’ histoire est réalisée. La définition du DONE est importante et peut varier suivant les types d’ histoires et la définition initiale donnée en cours de Sprint 0 ou de Discovery & Framing. C’est, en général, le Product Owner qui déplace en DONE.
• POSTPONED : Cette histoire a été mal estimée ou un problème a été rencontré en cours de Sprint. Elle est renvoyée à un Sprint suivant.

Labels de portée :

• SECURITY : Cette histoire a une notion de sécurité. Elle est traitée par les membres spécialisés en sécurité.
• PERFORMANCE : Cette histoire a une notion de performance. Elle est traitée par les membres spécialisés en performances.
• DOC : Cette histoire a une notion de documentation. Elle est traitée par les membres spécialisés en documentation.
• TEST : Cette histoire a une notion de test. Elle est traitée par les membres spécialisés en test.

Scrum Board

Les histoires du Sprint Backlog peuvent être présentées sur un Scrum Board.

C’est un tableau à colonnes. Chaque colonne représente un label d’avancement. Les colonnes sont organisées de gauche à droite selon l’ordre logique des labels d’avancement.

L’idée est de faire avancer les histoires de la gauche (TODO) vers la droite (DONE). Une équipe agile efficace a toutes les histoires en DONE à la fin du Sprint.

Sources

• L’expérience Limawi
• Unow

La cérémonie est la réunion qui permet de rassembler l’équipe agile (l’équipe de développement), le Scrum Master (le « manager » de l’équipe) et le Product Owner (le représentant du client) et éventuellement les clients.

Elle intervient généralement entre les sprints, donc à intervalles réguliers.

Cet évènement est divisé en plusieurs phases. Certaines équipes choisissent de disjoindre ces phases pour alléger les réunions.

Phase 1, en début de projet (sprint planning meeting)

Maître de cérémonie : Le Product Owner assisté du Scrum Master

Durée : moins de 2 heures.

Cette phase permet de détailler une grande partie des histoires sous forme de stories, NFR ou Spike et de les répartir tous au long des sprints prévus.

Elle permet d’estimer les grandes lignes du projet. Elle se concentre aussi sur la cohésion d’équipe et la découverte de l’équipe avec les clients et le projet.

Le but est de lancer le premier Sprint (Sprint 1 ou Sprint 0) dans des bonnes conditions.

Phase 1, en cours de projet (Sprint review)

Maître de cérémonie : Le Product Owner assisté du Scrum Master

Durée : moins d'1 heure.

Cette phase permet de faire le point sur le Sprint précédent. Au sein de cette phase, l’équipe agile explique à l’ensemble des acteurs du projet le résultat du Sprint. Des démonstrations peuvent être effectuées durant cette phase auprès des clients, d’utilisateurs finaux, d’un panel représentatif…

Les clients à travers le Product Owner doivent avoir une idée de l’état du projet.

Lors de cette étape, l’ensemble des acteurs font leurs retours à l’équipe agile. Il ne faut pas hésiter, c’est là qu’on peut réorienter le projet et préparer la phase 2.

Petit bonus Limawi, entre les deux phases

Maître de cérémonie : Aucun, c’est un jeu de cartes

Cette inter-phase consiste à revoir les modèles de menaces grâce au jeu «  Elevation of Privilege ». Cette méthode est expliquée dans un article dédié.

Phase 2, centrée sur le projet (product backlog refinement)

Maître de cérémonie : Le Product Owner assisté du Scrum Master

Durée : moins d'1 heure, peut être très rapide.

Cette phase permet de réorganiser les histoires ( Stories, NFR, Spike) pour le prochain Sprint. L’équipe agile questionne le Product Owner sur les histoires afin qu’elles soient les plus claires possible. L’équipe, ensuite, estime la charge de travail de l’ensemble de ces histoires (sous forme de points de complexité ou de temps) en utilisant le Poker agile. Une fois les histoires estimées, le Product Owner les priorisent en fonction de la vélocité de l’équipe. Il les place en « TODO » et renvoie celles en trop dans le Backlog (en « POSTPONED »).

Cette phase peut intervenir par petites touches tout au long du Sprint. Dans ce cas, le Product Owner peut affiner bien mieux et plus rapidement selon les difficultés rencontrées par l’équipe. Si cette façon de faire est préférée, alors la phase au sein de la cérémonie peut être très courte.

Phase 2, centrée sur l’équipe (Sprint retrospective)

Maître de cérémonie : Le Scrum Master

Durée : moins d'1 heure.

Cette phase permet de se concentrer sur la santé de l’équipe. Elle peut se faire sous forme de jeux. Elle permet de renforcer la cohésion de l’équipe et une amélioration continue.

Le but de cette phase est que l’équipe soit remotivée, que les difficultés de relations sociales entre les membres de l’équipe soient considérées et que l’environnement de travail soit amélioré.

Sources

• L’expérience Limawi
• My Agile Partner

« Discovery and Framing » sont 2 termes associés (la découverte et l’encadrement) qui qualifient une phase initiale précédant les sprints.

Cette phase permet de dégrossir un projet et de le formaliser pour pouvoir le conduire en méthode agile. Elle s’étale généralement sur une semaine.

Cela s’articule en 2 parties, la découverte et l’encadrement (d’où le nom).

La découverte

Elle commence le lundi et s’arrête si possible le mercredi.

Chaque jour, on détaille des hypothèses sur le projet et on interroge les clients (beaucoup). Une réunion a lieu tous les matins pour rassembler les résultats et recommencer (ça s’apparente au scrum).

Ne cherchez pas à estimer des temps, c’est une phase de recherche. Si cette phase déborde trop au delà du mercredi, il faudra peut-être planifier une nouvelle semaine.

L’encadrement (la formalisation)

À partir du mercredi, vous pouvez commencer à créer des ateliers au sein des équipes. Ces ateliers ont pour objectifs de définir les grands identifiants du projet :

• Les « buyers personas » et les «  final users personas » : cette technique est souvent utilisée en marketing pour cibler les marchés. Dans le cas présent, il faut voir plus large et plus technique. Comment les utilisateurs finaux vont-ils se servir du système ? Quels sont leurs cultures, leurs histoires pour prévoir l’ergonomie du système ?

• Déterminer quel est l’objectif minimum viable à atteindre. C’est à dire l’ensemble des fonctionnalités absolument nécessaires pour la première version du système. C’est le « Minimum viable product » (le produit minimum viable).

• À partir des ces données, extraire un Lean Canvas qui servira de fiche globale du projet.

• Déterminer l’environnement de développement nécessaire et les outils pour pouvoir développer, tester et mettre en production cette première version.

• Commencer à détailler les epics, sagas, themes et initiatives du projet mais pas encore les stories, NFR et Spike. L’objectif est d’avoir une vision du projet à long terme.

Bouclage et suite

Cette semaine se boucle avec une réunion de rétrospective (rappelant la cérémonie) durant laquelle on fait le point. Bien sûr, cette réunion ne doit pas dépasser 2 heures pour être efficace.

Cette phase de Discovery & Framing peut se répéter (s’itérer) sur plusieurs semaines jusqu’à ce que l’ensemble des acteurs du projet soient satisfaits des grands identifiants.

Une fois cette phase finie, alors les Sprints démarrent. Selon le projet, on peut caler un Sprint 0 à ce moment-là, qui sert de Sprint de chauffe.

Sources

• L’expérience Limawi

• My Agile Partner

Il y a plusieurs types d’histoires mais elles ont en commun d’avoir un objectif, de pouvoir être estimées (ou décomposée en éléments estimables) et d’avoir une définition du « DONE » claire (une fin claire).

Ces unités permettent de décomposer un projet clairement afin de pouvoir être réalisé de la façon la plus efficace possible.

Voici un panel (non exhaustif) des différents types d’histoire

• Tâche : Pas vraiment une histoire en tant que telle mais c’est l’unité atomique sur laquelle une histoire est construite. Elle doit être la plus simple possible. Par exemple, si l’histoire consiste à « rentrer dans une maison », la tâche est « poser la main sur la poignée de porte », la tâche suivante « tourner la poignée », etc.
• Story : C’est le type d’histoire le plus connu en méthode agile. Elle est centrée sur l’interaction avec l’utilisateur final. Pour ne pas confondre histoire et Story en anglais, le terme « User Story » est préféré. Elle permet de réaliser une fonctionnalité.
• NFR : C’est le type d’histoire le plus dur à définir. NFR veut dire « Non functional requirements ». Ce sont toutes les actions nécessaires à la bonne marche du projet mais qui n’affectent pas l’interaction de l’utilisateur final avec le projet. Par exemple, une refactorisation de code, un changement de licence, la mise en place d’un nouveau serveur de développement ou d’une machine à café pour l’équipe.
• Spike : Cette histoire permet de formaliser les étapes de recherche. Elle a une définition du DONE différente des autres car le principe de la recherche est qu’on ne sait pas ce qu’on va trouver.
• Epic : Cette définition varie suivant qui l’utilise. Généralement, elle définit une histoire dont l’estimation dépasse la possibilité d’un Sprint. Elle doit donc être découpée en histoires plus petites.
• Initiative : Utilisée par JIRA. Elle regroupe un ensemble d’Epics qui sont liées par un but commun.
• Thème : Cette histoire regroupe des Epics ou initiatives dont l’ensemble une fois fini forme un changement majeur pour une large portion de l’organisation (ou entreprise).
• Saga : Ce terme est peu utilisé (mais je l’aime bien) et peut se confondre avec le thème ou l’initiative. Il donne une note plus dans la continuité du terme « épique ». Il peut permettre de définir la racine du projet, de l’arbre des histoires. Du coup, je propose « Yggdrasil » pour nommer l’arbre des histoires, pour rester consistant dans les termes.

Début et fin d’histoire

Chaque histoire doit avoir une définition claire du READY (ou TODO) et le plus souvent du DONE.

C’est à dire que le Product Owner et l’équipe agile doivent s’accorder sur les prérequis nécessaires au démarrage de l’histoire (le READY). Pour le DONE, ils doivent définir le cahier des charges qui permet de s’assurer qu’une histoire est réellement finie. À noter que des histoires comme l’epic, le thème, l’initiative ou la saga n’ont pas de définition de DONE si ce n’est le DONE de toutes les histoires qui les composent.

Certaines histoires en détail

La User Story

L’histoire la plus connue de la méthode agile. Ce type d’histoires permet de créer de la valeur fonctionnelle pour l’ utilisateur final.

Une définition du READY : Une story doit avoir un départ clair selon l’acronyme INVEST ci-dessous :

• Independent: Chaque Story doit être indépendante de tout autre tâche.
• Negociable: Chaque story doit pouvoir être discutée pour décrire au mieux le parcours utilisateur qu’elle fournit :
  • Given a state (étant donné un état)
  • When an action (quand une action)
  • Then a result (alors un résultat)
• Valuable: Chaque Story doit effectivement apporter de la valeur au produit du point de vue de l’ utilisateur final.
• Estimable: Chaque Story doit pouvoir être estimée en tant que nombre de points de complexité qui aboutissent à une estimation du temps.
• Small: Chaque Story doit être suffisamment petite pour pouvoir être réalisée par une ou peu de personnes dans un Sprint.
• Testable: Chaque Story doit pouvoir être testée dans un outil de test en intégration continue.

Une définition du DONE : Une Story doit avoir une fin claire définie à l’avance avec un certain nombre d’objectifs à définir.

Exemple de DONE :

• Documentation générée
• Tests fonctionnels passés
• Tests de sécurité passés

Le NFR

Le NFR est un type d’histoire agile qui ne s’occupe pas de l’ utilisateur final.

Le NFR signifie « Non functional requirements » (requis non fonctionnels).

Il permet de résoudre les tâches nécessaires au bon déroulement du projet mais qui n’ont aucune visibilité pour l’ utilisateur final.

Exemple :

• Questions légales
• Questions de sécurité
• Questions d’organisation
• Questions de performances
• Questions d’infrastructures

Un NFR a peu de différence avec la Story à l’exception de l’aspect centré sur l’ utilisateur final.

Un NFR doit être SMART  :

• Specific: compréhensible par tous
• Mesurable: avec un DONE (un objectif) clairement défini
• Achievable: réalisable
• Relevant: pertinente
• Time-Boxed: court dans le temps et estimable en points de complexité

Il doit avoir une claire définition du READY et du DONE.

Le Spike

Quand on veut faire de la recherche en méthode agile, on utilise ça.

Le Spike (la pointe) cherche à préciser les étapes, savoirs et temps nécessaires pour résoudre les Stories et NFR.

Il doit être indépendant et testable ; mais il est, par essence, non estimable. En effet, quand on cherche on ne sait pas ce qu’on va trouver donc impossible d’estimer.

Pour pallier à ce manque d’estimation, il est time-boxé (avec un temps défini).

Exemple : Rechercher un remplacement pour CouchDB en 24 heures (3 jours)

Un Spike doit être SMART :

• Specific: compréhensible par tous
• Mesurable: avec un DONE (un objectif) clairement défini
• Achievable: réalisable
• Relevant: pertinente
• Time-Boxed: court dans le temps

Il doit avoir une claire définition du READY et du DONE.

Le DONE, dans ce cas, définit l’objectif, la direction de la recherche. Il permet d’estimer si la recherche est valable.

En effet, si l’objectif est de rechercher une nouvelle méthode pour faire une tarte à la framboise et que le résultat de recherche est un ensemble de méthodes pour créer ses croquettes pour chat, et bien ce n’est pas DONE.

Sources

• L’expérience Limawi
• Scrum Expert
• My Agile Partner
• Atlassian

Modèle de menace

Un modèle de menace est un outil qui permet de déterminer à l’avance les fragilités d’un système et les moyens d’y remédier.

Dans la méthode agile, il est continuellement mis à jour. Il doit suivre le produit existant et s’adapter rapidement aux nouvelles évolutions.

Comment y parvenir ?

Schémas et diagrammes

Dans un premier temps, il est nécessaire de documenter votre projet. Il doit avoir des représentations visuelles de ses composants et des flux d’informations.

Une des manières de représenter ces données est le langage UML. Le problème est que ce langage est complexe à écrire et à mettre à jour pour un être humain.

Il est donc préférable d’automatiser au maximum la documentation et ses diagrammes (qu’ils soient en UML ou une autre représentation) pour pouvoir les produire facilement à chaque évolution du projet.

Si les diagrammes sont faits manuellement, des dessins de patates suffisent. Il faut juste qu’ils soient compréhensibles par tous les membres de l’équipe.

Une fois ces diagrammes faits, on va pouvoir les étudier pour en déceler les failles. Et ce, de façon ludique, grâce au jeu « Elevation of Privilege ».

Les règles du jeu

Pour cela, prévoyez une phase de la cérémonie de sprint dédiée à ça.

L’équipe est assise autour d’une table. Le diagramme de la partie du projet à analyser est étalé sur la table visible de tous.

Le jeu de carte « Elevation of Privilege » est disponible en dessous.

Distribuez toutes les cartes aux joueurs. La partie commence avec le « 3 of tampering ». Jouez dans le sens des aiguilles d’une montre.

Cela ressemble beaucoup aux règles du Tarot.

Chaque joueur continue dans la même suite s’il a une carte dans la suite. Sinon, il joue une carte d’une autre suite.

Chaque pli (un tour de table) est gagné par celui qui a la plus haute carte dans la suite demandée au départ, sauf si une carte « Elevation of Privilege » est jouée (dans ce cas c’est la plus forte de ces cartes qui l’emporte).

Pour jouer une carte, le joueur doit l’annoncer et essayer de trouver sa menace sur le diagramme. Le système peut être résistant à cette menace. Dans ce cas, il est impossible de trouver la menace sur le diagramme.

Le joueur doit annoncer clairement sa menace. Pour être valide, elle doit amener à la création d’une histoire ( NFR d’ouverture de bug, User Story…) dans le projet.

À la fin du pli (quand tous les joueurs ont posé une carte de leur main), tous ceux qui ont réussi à trouver leur menace sur le diagramme ont un point. Si celui qui a gagné le pli a réussi aussi à trouver sa menace sur le diagramme, il gagne un point supplémentaire.

Le gagnant du pli démarre le pli suivant et choisit la suite de départ. Prenez quelques minutes entre chaque pli pour étudier les menaces.

Les cartes « Elevation of privilege » gagnent sur toutes les autres. Elles ne peuvent être jouées que quand le joueur n’a pas de carte dans la suite demandée (ou si la suite demandée est elle-même « Elevation of privilege »).

Les « As » sont des cartes qui permettent de trouver des menaces non prévues dans la suite demandée. Le joueur doit expliquer la menace elle-même.

Quand toutes les cartes ont été jouées (tous les plis ont été faits), celui qui a le plus de points l’emporte.

Annotez votre diagramme en fonction des menaces trouvées.

Vous pouvez faire passer les mains d’un joueur à l’autre entre chaque pli. Cela permet que les joueurs spécialisés puissent jouer des cartes que des joueurs précédents ne comprenaient pas.

D’autres joueurs que celui qui annonce sa carte peuvent surenchérir sur sa carte en trouvant la menace annoncée à d’autres emplacements que ceux trouvés par celui qui joue. Ils gagnent un point supplémentaire.

Téléchargez « Elevation of Privilege » et son extension « Elevation of Privacy », avec les règles EoP et une planche de dos de cartes.

Sources

• EoP, license Creative Commons attribution 3
• Eop (extension privacy), licence Creative Commons
• EoPrivacy, license Creative Commons attribution 4

Le Lean Canvas permet de décrire rapidement un projet sans oublier des éléments importants.

Il est utilisé par les startups pour démarrer leur projet mais peut être utilisé en méthode agile pour garder la cohérence du projet entre les multiples acteurs.

En effet, un bon Lean Canvas permet à l’équipe ou aux équipes agiles de prioriser les histoires ou de les réécrire, en accord avec le Product Owner, pour ne pas dévier d’objectifs à plus ou moins long terme voulus par les clients.

Présentation d’un Lean Canvas

• La case « Problème » (Problem) permet de définir l’objectif du projet. Elle permet de maintenir le cap lors de la conception des Users Stories.
• La case « Solution » permet de définir l’objectif minimum viable à atteindre avant une mise en production. Il faut prioriser les Users Stories de développement en fonction.
• La case « Indicateurs de performances » (Key Metrics) permet de définir les NFR prioritaires.
• La case « Proposition de valeur unique » (Unique Value Proposition) permet de définir les Users Stories de développement et NFR prioritaires dès la mise en production.
• La case « Avantage compétitif » (Unfair Advantage) permet de définir les Spikes prioritaires dès la mise en production.
• La case « Canaux » (Channels) permet de définir les Users Stories de marketing à prioriser.
• La case « Segments de clientèle » (Customer Segment) permet de définir les user personas (dont les buyers personas si le projet inclut du marketing).
• Les cases « Coûts » (Cost Structure) et « Sources de revenus » (Revenue Streams) peuvent faire l’objet de NFR. Leur analyse permet de prioriser certaines histoires (les histoires qui coûtent le plus dans les sprints au cours desquels les sources de revenu fonctionnent le mieux et inversement).

Si on regarde au niveau des histoires, le Lean Canvas est la représentation visuelle de la Saga.

Téléchargez notre template de Lean Canvas (au format odg, LibreOffice et OpenOffice).

Sources

• L’expérience Limawi
• L’inventeur du Lean Canvas
• Business Builder

L’unité de temps de la méthode agile « Scrum » est le Sprint. C’est une période qui se répète. Elle peut varier suivant les équipes, de 2 semaines à 1 mois..

C’est au cours de cette période que sont réalisées les histoires.

Elle est encadrée par une cérémonie de début, qui prépare le travail, et une cérémonie de fin, qui fait un bilan du travail accompli.

Au matin de chaque jour de travail de cette période a lieu la réunion journalière (ou Scrum) qui permet de maintenir les objectifs du Sprint.

Les objectifs d’un Sprint sont simples, faire passer de TODO à DONE toutes les histoires qui ont été prévues pour celui-ci.

Cas particulier, le Sprint 0

Le Sprint 0 est le tout premier Sprint qui arrive juste après la phase de Discovery & Framing. Ce Sprint là sert surtout de phase de rodage pour l’équipe.

Elle découvre l’environnement de travail, le déroulement des réunions journalières, l’ensemble des acteurs du projet, etc…

Contrairement à ce qu’on peut lire dans diverses sources, je ne conseille pas de décrire le produit et sa cible dans ce Sprint, la phase de Discovery & Framing est plus adaptée pour ça.

Ce Sprint doit ressembler au maximum à un Sprint normal tout en se rappelant que l’équipe découvre le sujet.

Ce Sprint n’étant pas efficace pour le développement brut du projet, il est compté à part.

La mêlée (le Scrum)

Le Scrum (« mêlée » en français) est la réunion journalière qui a lieu tous les matins. Elle donne son nom à cette forme de méthode agile.

Cette réunion doit se faire debout (on l’appelle aussi « Stand-up meeting » ). Elle ne concerne que l’équipe de développement. Elle est animée (mais pas « dirigée ») par le Scrum Master.

Chaque membre de l’équipe doit pouvoir s’exprimer. Il détaille ce qu’il a fait la veille et ce qu’il compte faire aujourd’hui. Si des obstacles apparaissent, le Scrum Master peut décider soit de les résoudre immédiatement (s’ils sont rapides à régler) soit de planifier une discussion à un autre moment.

La réunion ne doit pas dépasser un quart d’heure. Elle doit se dérouler à la même heure et au même endroit tous les jours (généralement avec un « Scrum Board » sous les yeux).

Cette réunion est aussi un point de rencontre sociale entre les membres de l’équipe. Peu à peu, le Scrum Master doit pouvoir s’effacer au profit d’une prise en main de la réunion par l’équipe (toute l’équipe), renforçant un esprit d’équipe.

L’idée est que les membres de l’équipe aient un moment pour s’entraider et retrouver une vision globale du projet. Ce n’est pas un reporting (ça, ça s’automatise et c’est face à face avec le Scrum Master si nécessaire).

Les 3 questions à laquelle répond cette réunion sont (pour rappel) :

• Qu’est ce qui a été fait hier ?
• Qu’est ce que vous comptez faire aujourd’hui ?
• Quels sont les obstacles rencontrés ?

La mêlée de mêlées

Si un projet nécessite plusieurs équipes agiles, on peut envisager une mêlée constituée d’un représentant de chaque équipe agile (pas le Scrum Master). Cette mêlée de représentants se déroule après la mêlée d’équipe.

Sources

• L’expérience Limawi
• Nutcache

Il est parfois compliqué de savoir par qui le résultat du projet sera utilisé. C’est là que le user persona intervient. Ils sont la représentation concrète des cibles utilisateurs du projet.

La fiche personnage

Un user persona ressemble à une fiche de personnage de jeu de rôle (pour les connaisseurs). Cette fiche permet d’avoir d’un coup d’œil l’ensemble des caractéristiques d’une personne.

À travers cette fiche, on cherche à connaître ses centres d’intérêt, son histoire, sa culture… On crée une personne physique de toute pièce.

Les ateliers du Discovery & Framing dédiés au user persona permettent de faire vivre cette personne, de lui donner de la consistance. N’hésitez pas à faire du jeu de rôle avec.

Il est par contre crucial de ne pas faire intervenir la relation éventuelle de la personne avec le résultat du projet. Cela risquerait de fausser les caractéristiques de la personne.

En marketing agile

Il est inutile de présenter ce concept en marketing car il est bien connu de tous. Cette fiche permet de définir les vecteurs d’acquisition, les moyens de toucher la cible.

C’est à elle que s’adresse les Stories (ou User stories). C’est cette cible qui effectue l’action décrite au sein de ces Stories.

Il ne faut pas, par contre, avoir peur de la modifier, de l’affiner au cours des Sprints.

On peut même être amené à la remplacer totalement si on se rend compte que la cible du projet change.

En développement agile

Cette fiche est utile pour orienter l’ergonomie et la priorité des fonctionnalités demandées par le client.

En adéquation avec le Product Owner, les développeurs ont un sujet de discussion pour décrire au mieux les User stories.

Là aussi, cette fiche effectue l’action décrite dans les User stories.

Il est donc utile d’avoir plusieurs user persona selon les rôles des utilisateurs du projet. Un user persona pourra représenter un administrateur du projet, un autre un simple utilisateur.

En projet de développement pur (dans lequel c’est le client qui s’occupe du marketing), les user personas sont décrites en Discovery & Framing et validées par le client.

En projet incluant du marketing, les user personas peuvent être modifiées par les équipes marketing avec une validation des équipes de développement. Dans ce cas, le Buyer persona doit aussi être inclus (celui qui achète le résultat du projet mais ne l’utilise pas forcément).

On peut même imaginer qu’un représentant de l’équipe marketing devienne le Product Owner (ou un adjoint du Product Owner) auprès de l’équipe de développement, puisqu’il est sensé mieux connaître les user personas.

Téléchargez notre  template de User persona (au format odg, LibreOffice et OpenOffice).

Sources

• L’expérience Limawi
• Ricoh
• Just in Mind

Le poker agile se présente sous la forme d’une suite de cartes dont chaque personne reçoit un paquet complet. Lors de la cérémonie de Sprint, l’équipe se sert des cartes pour évaluer la complexité des histoires ( User Stories, NFR ou Spike) envisagées.

Le point de complexité

Pour calculer la difficulté à réaliser une histoire, le premier réflexe serait de déterminer une durée.

Cette approche peut amener à un créer un environnement anxiogène. En effet, un développeur (marketeur ou autre) en charge de l’ histoire pourrait se sentir piégé par le temps et réaliser l’histoire trop vite et mal.

Bien sûr, la phase de revue permet de pallier à ce problème en faisant refaire des parties de l’ histoire encore et encore mais c’est une perte de temps, d’énergie et de ressources.

Alors, voilà le point de complexité.

Cet outil permet de déterminer une valeur de complexité de l’ histoire. Cette valeur peut être définie en rapport avec les autres histoires ou en valeur absolue.

En développement logiciel, on peut calquer la valeur du point de complexité agile sur la complexité du code à réaliser. Par exemple :

• une classe = 1 point, 3 classes = 3 points
• 1 point par méthode
• via une complexité calculée (par exemple en PHP)

Chaque histoire se voit assigner des points de complexités par l’intermédiaire du Poker agile.

La vélocité

Le point de complexité n’est pas corrélé à une durée. Du moins dans un premier temps.

Lorsqu’une équipe agile commence à être bien rodée (c’est à dire après quelques Sprints), on peut commencer à voir le nombre de points de complexité moyen que l’équipe peut réaliser par Sprint.

C’est la vélocité.

C’est une approche par paquet mais il peut être problématique de vouloir trop détailler le temps moyen passé par point de complexité car on reviendrait à une situation trop anxiogène.

Une fois une vélocité moyenne estimée, l’idée est de pouvoir mesurer la performance de l’équipe et de chercher à maintenir cette vélocité.

Il n’est pas forcément avisé de chercher à l’accroître, pour éviter, encore une fois, de revenir à une situation anxiogène.

Les règles du Poker

À chaque histoire, chaque membre de l’équipe choisit une carte dans son paquet et la garde pour lui, face cachée. Cette carte représente son estimation de la complexité de l’ histoire.

Quand tous les membres de l’équipe ont choisi leur carte, tout le monde retourne ses cartes en même temps.

Ceux qui jouent les cartes les plus éloignées de la moyenne expliquent plus particulièrement leur point de vue. Un consensus se forme alors sur la complexité estimée par l’équipe.

Les paquets de cartes disponibles, ci-dessous, sont au nombre de 7 (une équipe agile de taille standard). Ils sont différentiables par leur couleur.

Chaque paquet contient :

• une suite de Fibonacci : pour des estimations précises ou des jours de travail (pour des Spikes) en utilisant la grille au centre (une colonne représente une semaine complète) ;
• des tailles de T-shirt : pour des estimations moins précises ;
• un positif et un négatif : pour approuver ou désapprouver ;
• un point d’interrogation : quand on n’a aucune idée ;
• un café : quand il est temps de faire une pause ;
• un infini : quand l’ histoire est trop grande et qu’il faut la décomposer.

Téléchargez le jeu complet ainsi que des dos de cartes.

Sources

• L’expérience Limawi
• Atlassian

La version 0 :

Les extensions :

Séparer logiciels et données

Tout d’abord, il faut définir ce qu’on veut sauvegarder. Un ordinateur ou un smartphone contient des données utilisateurs mais aussi des logiciels et leurs fichiers de configuration.

Quand on fait une sauvegarde, on pense, bien sûr, aux données mais on oublie parfois les fichiers de configuration des logiciels. Doit-on les sauvegarder avec les données ?

Et bien, ça dépend des cas.

Images système/points de restauration

Il y a deux cas de figure pour les fichiers de configuration. Soit ils sont valables pour tous les utilisateurs de l’appareil, soit ils ne sont valables que pour un utilisateur uniquement.

Les fichiers de configuration concernant tous les utilisateurs devraient être considérés comme des logiciels et ne pas être compris dans les sauvegardes de données. Il est préférable d’utiliser des outils d’images système et des points de restauration. La technique d’image système permet de réinstaller rapidement un système avec tous les logiciels que vous avez défini sans devoir tout reprendre à zéro. Elle permet aussi d’être distribuée pour être installée sur plusieurs appareils.

Les fichiers de configuration concernant un seul utilisateur devraient être considérés comme de la donnée et sauvegardés de la même manière que les données. Ils ont potentiellement des données personnelles propres à l’utilisateur et ne peuvent donc pas être redistribués comme les images système.

Conserver le minimum de données dans les smartphones

Le deuxième élément à considérer, avant de sauvegarder les données, est l’usage des données dans les smartphones.

La taille de l’espace de stockage dans les smartphones est réduit. Il faut donc un moyen de pouvoir libérer le smartphone des données en trop et les stocker ailleurs.

Mais aussi la probabilité de vol ou de perte d’un smartphone est élevée.

La complexité des sauvegardes est plus forte à cause de l’accès réseau qui est plus aléatoire. Vouloir sauvegarder des données en EDGE reste une illusion.

L’accès réseau est important car il vaut mieux sauvegarder ses données à distance que dans le même appareil pour éviter de les perdre avec l’appareil.

Comment sauvegarder les données ?

Synchronisation

La toute première façon de sauvegarder les données est la synchronisation. C’est la façon la moins sûre, mais la plus dynamique.

La synchronisation, avec un outil comme Nextcloud par exemple, est proche de l’instantané. Cela permet d’avoir une copie de vos données actuelles sur un serveur distant.

Vous pouvez associer un outil de versionnage à cette synchronisation. Avec un versionnage, vous pouvez revenir à une version antérieure de vos fichiers à partir de votre serveur distant.

Ce système est peu sûr car, si vous effacez un fichier sur votre ordinateur ou smartphone, la synchronisation peut l’effacer à distance (ou, du moins, effacer la dernière version en cas de versionnage).

Il offre, par contre, une protection contre la casse de votre système. Si votre ordinateur ou votre smartphone s’éteint d’un coup et ne redémarre plus, vous pouvez récupérer vos fichiers jusqu’à quelques minutes ou même secondes avant la panne.

« Incrément vs full »

En plus de la synchronisation, vous pouvez utiliser un outil de sauvegarde spécifique. Il fonctionne en créant une sauvegarde journalière ou hebdomadaire suivant la façon dont vous le paramétrez. Il charge ces données sur un système distant comme un serveur ou un disque externe. C’est le système présent par défaut dans Windows, macOS avec TimeMachine ou Ubuntu avec Deja-dup.

Ce système est plus sûr que la synchronisation mais il ne permet pas de sauvegarder les données à tout instant. Il sauvegarde les données présentes quand il est actif, donc si vous l’activez à 3 heures du matin tous les jours, il sauvegardera les données à ce moment là. Si un problème survient à 2 heures du matin, et que toutes vos données sont effacées sur votre appareil, vous aurez perdu une journée de données.

Mais il est plus sûr car les fichiers sauvegardés ne sont pas actifs. Si un virus s’est faufilé dans les fichiers, il ne peut pas agir. Si vous effacez un fichier sur votre ordinateur, il ne sera pas effacé dans votre sauvegarde.

Un incrément c’est la différence de fichiers entre l’état actuel du système qu’on sauvegarde et l’état dans lequel était le système à la sauvegarde précédente.

Ce système fonctionne avec une sauvegarde complète de toutes vos données au début (puis un incrément à chaque sauvegarde). Cela permet de gagner de l’espace de stockage et de la vitesse de sauvegarde car il y a beaucoup moins de données à charger sur le système distant.

Attention : si la sauvegarde complète, ou l’un des incréments, est corrompu, les incréments suivants ne fonctionneront plus. Faites des sauvegardes complètes à intervalle régulier (hebdomadairement ou mensuellement).

Sauvegarde froide/archivage

La façon la plus sûre de sauvegarder les données est la sauvegarde froide qui est utilisable aussi pour de l’archivage. Cela consiste à faire une sauvegarde sur des dispositifs sur lesquels la donnée ne peut pas être réécrite.

Vous pouvez graver des DVDs ou utiliser des systèmes de fichiers qui se mettent en lecture seule une fois les données écrites.

Ces dispositifs peuvent être automatisés pour sauvegarder automatiquement vos données mais ils fonctionnent généralement en mode « pull ». C’est à dire que ce n’est pas votre appareil qui leur envoie des données mais eux qui viennent prendre les données. Cela afin de limiter l’accès à ces dispositifs.

C’est le plus sûr, mais aussi le plus complexe à manier.

En dehors de la phase de sauvegarde, les dispositifs sont éteints et ne consomment pas d’énergie.

Comme les données, une fois écrites, ne peuvent pas être effacées c’est utile aussi pour de l’archivage.

Tester la récupération

Il y a une étape à ne pas oublier, une fois la sauvegarde effectuée. La tester.

En effet, si la sauvegarde se corrompt ou s’abîme et devient inutilisable, c’est comme si vous n’aviez rien sauvegardé.

La plupart des outils de sauvegarde ont un système permettant de tester la récupération. Utilisez-le à intervalle régulier.

Sources

• 20minutes
• lavoixdunord
• apple
• microsoft
• microsoft
• apple
• deja-dup
• Nextcloud

Pourquoi ?

L’argument d’espionnage

Selon The Times, la CIA rapporterait que Huawei est financée par l’Armée populaire de libération (l’armée chinoise), la commission de la sécurité nationale chinoise et une autre branche du renseignement chinois.

Selon la CIA, Huawei se servirait de ses appareils pour espionner le monde entier. Elle pourrait se servir de ses installations 5G en négociations en Europe, et ailleurs, pour renforcer encore cet espionnage.

Mais la situation n’est pas aussi simple que ça.

Guerre commerciale USA-Chine

Le bannissement de Huawei du marché américain intervient dans un contexte de guerre commerciale entre la Chine et les États-Unis.

Le président américain, Donald Trump, s’est servi de l’argument de sécurité nationale pour exclure Huawei, un poids lourd de l’économie chinoise.

Les européens réagissent de manière non coordonnée et on ne sait pas aujourd’hui quelles seront les décisions finales à ce sujet.

Les États-Unis ont menacé l’Europe pour faire exclure Huawei, mais sans succès, pour l’instant.

Sauf que le 23 Mai, lors d’une conférence de presse, Donald Trump déclare que Huawei pourrait réintégrer le marché américain à l’issue d’un accord commercial avec la Chine. Ça met un peu à mal l’argument de sécurité nationale.

Risques des sanctions pour Huawei

Alors, quels sont les risques de ces sanctions pour Huawei ?

Un simple mot :

Catastrophique

Google a annoncé qu’il révoquait sa licence Android pour Huawei. Cela veut dire que les smartphones Android de Huawei ne pourront plus accéder aux services de Google, ni aux mises à jour de sécurité faites par Google. Huawei devra entièrement reconstruire un écosystème avec la version opensource d’Android.

Microsoft a annoncé qu’il coupait les ponts avec Huawei. Les ordinateurs Huawei ne pourront plus avoir Windows préinstallé et ceux déjà vendus n’auront plus de mises à jours (même celles de sécurité).

Et la liste continue. Qualcomm, Broadcom, Intel et ARM ont aussi annoncé l’arrêt des relations avec Huawei. Ce qui veut dire que Huawei n’a plus accès aux principaux fabricants de processeurs du monde.

Les processeurs étant indispensables au matériel informatique, c’est un énorme problème pour la production de smartphones et ordinateurs.

Mais Huawei avait anticipé ces problèmes car Donald Trump avait fait des déclarations annonçant potentiellement des sanctions. Et l’entreprise a acheté pour trois mois de matériel américain dans l’espoir d’avoir rétabli les relations avant cette échéance.

Donc, Huawei a introduit un recours à l’encontre de l’État américain, devant la justice américaine pour faire lever la sanction. L’entreprise fait valoir l’absence de preuve d’espionnage.

En attendant, le département du commerce américain a créé une licence générale provisoire, valable 90 jours, pour assouplir les restrictions sur les appareils existants. Cela afin d’éviter que les entreprises américaines utilisant du matériel Huawei soient trop pénalisées.

Pour ceux qui ont du matériel Huawei et qui s’inquiètent de comment ils pourront continuer à l’utiliser, je reviendrai prochainement dans une de mes vidéos et je donnerai des pistes pour s’en sortir au mieux.

Sources :

• la tribune
• arstechnica
• developpez.com
• numerama
• numerama
• numerama
• theverge
• numerama
• numerama
• clubic
• reuters
• clubic

STOP !!

Une clé USB trouvée par terre peut être le début de bien des problèmes.

De nombreuses arnaques ont lieu en se servant de clés USB. Beaucoup de gens sont curieux et ne s’en méfient pas. Quand ils en trouvent une par terre, ils la branchent à leur appareil pour en inspecter le contenu ou l’utiliser.

Une arnaque connue est simplement de poster des clés USB dans la boîte au lettres de particuliers. Une partie d’entre eux ne se méfiera pas et branchera ces clés sur leur ordinateur.

Le problème est que les clés peuvent contenir des virus, des logiciels espions ou autres gentillesses. Quand une clé USB est connectée à votre appareil elle a des accès suffisants pour lancer son attaque.

Ces attaques peuvent être du vol de données confidentielles, de l’infection de l’appareil pour être ajouté à un BotNet ou d’autres amabilités.

Alors, vous avez trouvé une clé USB et vous voulez vraiment voir le contenu ou l’utiliser ? On va parler « bac à sable ».

Le Sandboxing (bac à sable)

Pour vérifier une clé USB en toute ou relative sécurité, il faut la tester dans une Sandbox ou bac à sable.

Une Sandbox, c’est un environnement isolé du reste de vos appareils et d’Internet. Cet isolement assure que le virus potentiel ne peut pas se répandre.

Un environnement est un ensemble de logiciels et de matériels interagissant fortement ensemble. Par exemple, votre ordinateur Windows peut être défini comme un environnement. Si votre ordinateur est connecté à d’autres sur un réseau local, vous pouvez définir ce réseau local comme un environnement. Considérez les environnements comme des boîtes que vous pouvez empiler les unes à côté des autres ou les unes dans les autres. L’important, ce sont les interactions de cette boîte avec les autres qui doivent être connues et maîtrisées.

Votre Sandbox doit pouvoir être jetée, c’est à dire détruite, de façon sûre et complète. Ceci afin de pouvoir recommencer les tests sur des bases constantes et de s’assurer que l’environnement ne soit pas détourné plus tard.

Le Sandboxing n’est pas utilisé uniquement pour les virus et fichiers de provenance douteuse mais aussi pour les environnements de tests quand on développe des logiciels.

De plus, une Sandbox peut contenir des outils qui permettent de détecter des changements de fichiers, des tentatives d’accès au réseau ou des exécutions de programmes.

Il existe de multiples moyens de faire du Sandboxing suivant ce qu’on veut accomplir.

Voici les deux plus sûrs :

La machine virtuelle

La machine virtuelle est un logiciel qui permet de créer un ordinateur quasiment semblable à un véritable ordinateur. Cette machine peut être isolée de l’ordinateur qui la génère, qu’on appelle hôte. L’intérieur de cette machine ressemblant quasiment à un véritable ordinateur, vous pouvez voir comment la clé USB agirait sur un vrai ordinateur.

Il existe des outils opensource pour créer des machines virtuelles comme VirtualBox ou KVM.

Si vous êtes débutant, je vous conseille VirtualBox. Il n’est pas très compliqué à mettre en place.

Vous pouvez détruire votre machine virtuelle quand vous voulez.

Vous pouvez aussi faire des snapshots, c’est à dire sauvegarder votre machine à un certain état pour pouvoir y revenir.

Si vous développez et que vous utilisez votre ordinateur hôte pour tester votre code, utilisez plutôt une machine virtuelle (ou Docker dans une machine virtuelle mais je m’égare).

L’ordinateur (carrément)

Le meilleur environnement est l’ordinateur. Si vous avez un ordinateur que vous pouvez reformater comme bon vous semble, utilisez le.

Bien sûr, déconnectez le de tout réseau possible (Wifi, Ethernet, Bluetooth, infrarouge). Si vous êtes paranoïaque, passez votre ordinateur en Air-Gap.

Un Air-gap est un outil de sécurité qui consiste à rendre un ordinateur physique totalement isolé du reste du réseau. Cela veut dire bien sûr tous ses accès réseaux coupés mais aussi les accès physiques comme un champ électromagnétique. L’ordinateur doit être placé dans une cage de Faraday. Amusez-vous avec du papier d’alu.

Une fois que vous avez ouvert votre clé USB et vous êtes amusé avec votre Sandbox, reformatez votre Sandbox ou démarrez une machine virtuelle propre et reformatez la clé avant de l’utiliser ailleurs.

Même si la clé vous semble vide, un programme malveillant peut être caché. Reformater votre clé est le moyen le plus sûr qu’il n’y ait pas de virus.

Sources :

• france3-regions
• pcmag
• nakedsecurity
• journaldunet
• techopedia
• Korben et la cage de Faraday

WhatsApp est une application de messagerie qui chiffre les communications de bout en bout.

Le chiffrement de bout en bout consiste à chiffrer vos messages directement sur votre appareil. La communication qui est envoyée sur Internet par les serveurs de WhatsApp est déjà chiffrée. Seul votre correspondant peut la déchiffrer.

C’est intéressant car vous pouvez faire passer des communications en utilisant des serveurs dans lesquels vous n’avez pas confiance, ils ne pourront pas les déchiffrer.

La semaine dernière, Facebook, l’entreprise qui gère WhatsApp, a annoncé qu’une faille de sécurité sérieuse avait été trouvée.

Beaucoup de gens et médias ont annoncé que le chiffrement de bout en bout ne fonctionnait donc pas et n’était pas sûr.

C’est totalement faux.

La faille

Facebook a publié un identifiant CVE (Common Vulnerabilities and Exposures) expliquant la faille.

Un identifiant CVE, c’est un format de publication de failles permettant de les lister dans un dictionnaire pour pouvoir avertir rapidement les spécialistes.

En lisant cet identifiant, on se rend compte que la faille n’a rien à voir avec le chiffrement de bout en bout.

C’est en fait une faille qui apparaît quand on répond au téléphone à travers WhatsApp et qui met en cause la mémoire tampon.

La mémoire tampon est une partie de la mémoire ou du disque d’un appareil qui sert à stocker temporairement des informations pour qu’un logiciel puisse les réutiliser rapidement.

Le système alloue un emplacement sur cette mémoire à chaque logiciel.

Cette attaque consiste à envoyer des paquets d’informations à l’appareil de la victime quand elle répond au téléphone, en plus des paquets d’informations qui forment la communication.

Ces paquets profitent ensuite d’un « dépassement de tampon », c’est ça la faille. WhatsApp écrit ces paquets dans un emplacement sur la mémoire tampon du téléphone. Cet emplacement est normalement alloué à un autre logiciel ou n’est pas alloué du tout.

Ces paquets permettent d’espionner entièrement l’appareil.

Cette attaque ressemble et a été ensuite confirmée comme provenant du NSO-group. C’est une entreprise qui conçoit des logiciels espions pour les états. Cette attaque ressemble à ce que peut faire un de leur programme nommé Pegasus.

Il semble que NSO-group ait exploité la faille, c’est ce qui a déclenché sa découverte. Rien n’empêche d’autres groupes d’avoir fait de même sans que ce soit su.

Donc, si vous avez WhatsApp, mettez à jour avec la version officielle, disponible sur les App Stores !

Sources

• nakedsecurity.sophos.com
• facebook cve
• mitre

Votre appareil comme outil malveillant

Si vous ne sécurisez pas votre appareil (ordinateur et smartphone), il peut être infecté par un logiciel malveillant. Comme je l’ai déjà dit dans plusieurs vidéos, il peut être un élément supplémentaire dans un BotNet. Il peut prendre part à des agressions informatiques contre d’autres personnes ou organisations. Vous pourriez avoir des problèmes devant la justice et devoir justifier que votre appareil a effectivement été hacké.

Un BotNet ne sert pas uniquement aux attaques mais aussi au stockage. Les hackers peuvent se servir de votre appareil pour stocker des contenus illicites. Il y a déjà eu des cas de personnes ayant été poursuivies pour pédopornographie parce qu’on avait retrouvé des fichiers dans leur ordinateur. Ils ont été relaxés quand la preuve a été apportée que leur ordinateur avait bien été hacké. Mais leur vie a quand même été brisée.

C’est quelque chose de grave et à prendre sérieusement en considération.

Enfin, pour clore ce chapitre, vous avez probablement des moyens de paiement présents sur vos appareils. Il vaudrait mieux éviter qu’un hacker s’amuse avec vos comptes bancaires.

Vos données peuvent se retourner contre vous

Sur les données elles-mêmes, rappelez-vous que tout ce qui a été rendu public est extrêmement compliqué à privatiser à nouveau. Vous ne vous souciez pas de vos données personnelles ? Et bien, faisons le point.

Votre vie privée est liée à celle d’autres personnes (vos amis, votre famille). Quand vous publiez une information personnelle vous concernant, vous pouvez aussi, du même coup, diffuser des informations les concernant. Ils ne vous ont pas donné leur accord et ils ont peut-être des raisons, que vous ne connaissez pas, de ne pas vouloir diffuser ces informations.

Vos données personnelles peuvent aussi être détournées. De nombreuses personnes se font avoir et voient leur image circuler dans le monde entier pour des causes qu’elles ne cautionnent pas forcément. Une fois que ces photos sont diffusées, c’est très dur de les récupérer (surtout à l’époque des « memes »). Elles peuvent même être utilisées par des groupes terroristes ou néo-nazis.

Donc, protégez vos données personnelles.

Enfin, n’oubliez pas que l’espérance de vie dans le monde occidental est autour de 80 ans. Si vous avez 20 ans maintenant, vous n’avez aucune idée de ce que vous ferez dans 20 ans. Ne vous tirez pas une balle dans le pied. Vos données personnelles pourraient être retenues contre vous si vous cherchez à être recruté dans une entreprise, si vous gagnez en notoriété ou si vous poursuivez une carrière politique.

En conclusion, sécurisez vos appareils et faites attention aux informations que vous diffusez à votre propos ou à propos des autres.

Sources

• hg.org
• theatlantic
• lci

Ces emails commencent souvent par :

« J’ai hacké votre ordinateur car, regardez, je vous écris avec votre propre email ! »

Ou des variantes.

Effectivement, vous pouvez constater que c’est votre propre adresse email qui est l’expéditeur. Mais ça ne signifie pas que votre compte a été hacké.

Un peu d’histoire

L’email a été inventé en 1965, bien avant Internet. Il servait de moyen de communication entre ordinateurs et était loin de sa forme actuelle. Il n’y avait pas, au tout début, d’arobase. Les adresses email ont donc été inventées après le système lui-même. La première adresse était « omlinson@bbn-tenexa » sans terminaison de type « .com » ou « .org » car le système des noms de domaines n’était pas encore inventé.

Cet outil a donc été pensé avec les problématiques de son époque. C’était encore un système peu utilisé et les utilisateurs respectaient des chartes de bonne conduite qu’elles proviennent de leurs universités, de centres de recherches ou des entreprises.

L’usurpation d’identité n’avait pas été prise en compte, pas plus que le chiffrement des emails. Tout le monde pouvait envoyer un email en indiquant comme adresse de départ l’adresse email de n’importe qui. Et c’est toujours le cas.

Des normes

Bien sûr, comme pour le chiffrement des emails (rappelez-vous de « PGP » de Booba), de nouvelles normes ont tenté d’y remédier.

C’est le cas de la spécification DMARC qui implémente deux normes (DKIM et SPF). Cette spécification a pour but d’authentifier l’expéditeur de l’email. Elle donne alors au destinataire les règles à appliquer si l’authentification échoue.

Sauf que cette spécification n’est pas implémentée partout et que les règles à appliquer peuvent ne pas classer comme frauduleux l’email qui l’est, ou le classer comme spam, ce qui n’empêche donc pas l’email d’arriver dans la boîte de la victime et de produire son effet.

Donc, le fait que l’adresse de l’expéditeur soit votre adresse n’indique rien sur une éventuelle faille de votre système. Le spammer a simplement fait un programme avec la même adresse email pour l’expéditeur et le destinataire et a utilisé ce programme avec des millions d’adresses emails dont la vôtre.

Alors, comment s’assurer que ce qu’il avance est faux ?

Lisez l’email et vous noterez quelque chose. Entre les menaces, l’adresse Bitcoin pour payer et l’ultimatum, vous ne voyez apparaître absolument aucune information personnelle vous concernant ainsi qu’aucun moyen de contacter le prétendu pirate. C’est simplement parce qu’il n’a aucune information personnelle sur vous vu qu’il n’a rien piraté du tout.

Donc, direction les spams.

Il est à noter que nous avons reçu de multiples variantes de cet email. Nous avons la version classique, en anglais, la version plus rare en français, celle en allemand et celle pour les professionnels menaçant d’attaque DDOS contre notre infrastructure. Au passage, pour les attaques DDOS, en général les vrais pirates font une petite démonstration effective avant de menacer.

Comment devinent-ils la langue ou le fait que nous soyons professionnels ?

C’est parce qu’ils récupèrent les adresses emails dans des listes provenant de sites qui, eux, ont été vraiment compromis. Si les sites sont en français, alors les adresses emails ont un message en français, si les sites sont des sites de professionnels (comme par exemple Docker qui s’est, récemment, fait piraté sa base utilisateurs) alors les adresses email ont droit au message pour les professionnels.

Comme vous avez pu le voir dans l’épisode de Cryptotrucs sur de vieilles techniques de cryptographie, on ne faisait parfois que cacher le message.

Cette façon de faire est fortement déconseillée maintenant.

Il est bien plus sûr de connaître parfaitement un système sécurisé que de ne rien en connaître.

Pourquoi ?

Alors, attention ça va « name-dropper ».

Au 19ème siècle, Auguste Kerckhoffs établit des principes pour communiquer de façon sécurisée. Le deuxième principe, dont j’ai déjà parlé dans un épisode de Cryptotrucs, stipule que :

« Il faut que le système n’exige pas le secret, et qu’il puisse sans inconvénient tomber entre les mains de l’ennemi. »

Au 20ème siècle cette fois, Eric Raymond établit la loi de Linus (en l’honneur de Linus Torvalds, le créateur de Linux) :

« Avec suffisamment d’yeux, tous les bugs sont superficiels. »

Bruce Schneier précise le second principe de Kerckhoffs :

« Le principe de Kerckhoffs s’applique au-delà des chiffres et des codes, c’est-à-dire aux systèmes de sécurité en général : tout secret est en fait un point de cassure possible. Par conséquent, le secret est une cause première de fragilité, donc cela même peut amener un système à un effondrement catastrophique. À l’inverse, l’ouverture amène la ductilité. »

Et c’est là le coeur du problème avec le fait de cacher (l’obfuscation). On ne maîtrise pas le risque. Plus le secret est grand, plus il y a de risque de fuite.

Plus un système est caché, moins il est facile de le corriger, de le réparer et même de repérer s’il a été percé. Le fait de rendre le code d’un système public, le rendre opensource, permet de réduire ce déséquilibre entre attaquant (« hackeur ») et défenseur. On espère, en rendant le code public, augmenter le nombre de défenseurs et donc rendre le système plus fiable.

Le secret doit rester le plus petit possible. On utilise, en général, la clé de chiffrement.

Il y a un inconvénient à cette approche. Il faut forger une communauté autour du code. Parfois, des outils cryptographiques utilisés par tout le monde ne bénéficient pas d’une communauté suffisante pour que le code soit suffisamment testé (le « suffisamment d’yeux » de la loi de Linus).

C’était le cas d’OpenSSL. La communauté de développement d’OpenSSL a été trop réduite pendant des années et des failles de sécurité importantes n’ont pas été colmatées assez vite (la faille Heartbleed).

Cacher ou pas son code revient donc à une analyse de risques. Rendre le code public limite le risque de failles à condition qu’une communauté de développeurs se forme autour.

La 5G est la prochaine génération de réseaux mobiles succédant à la 4G. Elle offre un débit beaucoup plus élevé et une latence (un ping) beaucoup plus faible.

Ce réseau ne s’intéressera pas uniquement aux smartphones mais aussi à l’ensemble des objets connectés, comme votre frigo, votre machine à laver ou votre voiture.

Elle est aussi pensée pour remplacer l’Internet fixe.

Attention, la norme n’est pas encore finalisée. Ce sera le cas, normalement, fin 2019.

Le réseau s’appuiera sur des fréquences hautes. Des fréquences entre 3,5 et 50 GHz sont prévues mais ça peut encore évoluer. Les fréquences des réseaux actuels sont entre 0,7 et 2,6 GHz.

Les fréquences les plus élevées de la 5G sont des ondes millimétriques. C’est à dire que la distance parcourue par l’onde entre 2 oscillations est de l’ordre du millimètre. Une fréquence de 1 Hz, c’est une oscillation par seconde, une fréquence de 50 GHz, c’est 50 milliards d’oscillations par seconde.

Pourquoi ? Parce que ces fréquences permettent des bandes de fréquences beaucoup plus larges et moins chargées que les bandes actuelles. Une bande de fréquence c’est la différence entre deux fréquences et c’est ce qui est alloué à chaque opérateur téléphonique.

Entre 0,7 et 2,6 GHz, on a une bande de fréquences totale de 1,9 GHz à partager entre plein d’opérateurs.

Entre 3,5 et 50 GHz, on a une bande de fréquences totale de 46,5 GHz. Il y a beaucoup plus de place.

C’est plus pratique pour du haut débit.

L’inconvénient est que les bandes de fréquences hautes vont moins loin et traversent moins facilement les obstacles.

Pour compenser ça, la 5G prévoit deux systèmes. Le premier est le « beam tracking » (la focalisation). De multiples antennes pourront concentrer leurs ondes sur un appareil spécifique pour augmenter l’efficacité du réseau.

Le deuxième c’est le MIMO (Multiple input multiple outpout). Chaque antenne 5G s’additionnera aux autres pour améliorer le débit de l’appareil.

Ça veut dire que le réseau 5G sera beaucoup plus dense que les réseaux précédents.

Questions de cybersécurité

Des attaques contre la 3G et la 4G se développent de plus en plus. Il n’y a pas de raison que ça s’arrête pour la 5G.

Il y aura aussi une augmentation des surfaces d’attaque due à l’adaptabilité du standard à de multiples protocoles de communications.

Comme ou pourra se connecter de multiples façons au réseau 5G, il y aura de multiples possibilités pour un hacker d’entrer sur le réseau.

Le réseau 5G facilitera aussi les attaques par déni de service (DDOS).

Ce sont des attaques qui consistent à envoyer le plus de requêtes possibles sur un serveur ou une infrastructure pour le saturer complètement et l’empêcher de fonctionner.

Comme la bande passante sera beaucoup moins limitée et que beaucoup plus d’objets seront connectés, les BotNet gagneront en efficacité.

Un BotNet est un ensemble de milliers ou centaines de milliers d’objets connectés piratés. Ils obéissent aux ordres d’un serveur maître qui leur dit d’attaquer telle ou telle cible.

Questions environnementales

De nombreuses questions se posent à propos de l’interaction de ces ondes millimétriques avec le vivant.

Selon les études actuelles, le seul effet connu d’une onde millimétrique sur un organisme est l’effet thermique. Ce phénomène n’apparaît qu’avec des puissances bien supérieures à celles utilisées en télécommunications.

Il y a quand même des inconnues. Le standard 5G n’est pas finalisé. S’il admet des fréquences plus élevées de l’ordre du THz (1000 milliards d’oscillations par seconde), alors quelques études montrent des effets biologiques.

Pour l’instant, c’est un domaine mal connu. Il y a trop peu d’études sur les risques pour l’organisme liés aux :

• multiplications d’antennes,
• interactions de plusieurs antennes dans un même environnement,
• temps d’exposition à ces ondes,
• effets combinés de ces différents éléments

Donc, pour l’instant, je reste prudent. Je ne sais pas.

On ne manquera pas de revenir ici sur ce sujet d’actualité.

Sources

• Nextinpact
• Nextinpact à nouveau
• Inpact-hardware
• itsecurityguru
• itsecurityguru à nouveau
• Threatpost
• Espace-sciences
• sfrp

Sources :

• Clip officiel de Booba
• Site officiel de PGP
• Site officiel de GnuPG
• GnuPG sur mac OS
• GnuPG sur Windows
• GnuPG sur Android
• Cryptotrucs épisode 3, la cryptographie symétrique

Qu’est-ce que PGP ?

PGP est l’acronyme de « Pretty Good Privacy » qui veut dire « assez bonne vie privée ». PGP est un outil de cryptographie propriétaire appartenant à Symantec. Cet outil a été réécrit en opensource en 1997 sous une norme nommée OpenPGP. En 1999, une alternative entièrement opensource mais compatible avec OpenPGP a été publiée, c’est GnuPG ou GPG.

Je vous conseille GnuPG si vous ne voulez pas que ce soit « un peu plus cher » (dixit Booba) et c’est autant « de la qualité » voire plus.

Ce protocole sert à sécuriser l’échange et le stockage de données entre deux interlocuteurs. Il est basé sur un algorithme de cryptographie symétrique et un algorithme de cryptographie asymétrique.

Vous pouvez en apprendre plus sur la cryptographie symétrique en regardant l’épisode 3 de Cryptotrucs. (Spoiler alert : On abordera la cryptographie asymétrique dans l’épisode 4.)

GPG utilise deux fichiers de chiffrement. Un fichier sert à chiffrer et l’autre à déchiffrer. Ce fonctionnement repose sur la cryptographie asymétrique. Le fichier qui sert à chiffrer est nommé partie publique ou clé publique. Le fichier qui sert à déchiffrer est nommé partie privée ou clé privée.

L’avantage d’avoir ces deux fichiers est que vous pouvez diffuser, à tous vos contacts, la partie publique (d’où son nom, « publique ») et ne pas mettre en danger la sécurité de vos échanges. C’est la partie privée, que vous gardez pour vous, qui garantit cette sécurité.

Comment ça fonctionne ?

Un de vos contacts veut communiquer avec vous. Il utilise la partie publique que vous lui avez envoyée pour chiffrer son message. C’est comme un cadenas. Une fois le message chiffré, cadenassé, il ne peut plus le déchiffrer. C’est vous seul qui possédez la clé du cadenas.

Il vous envoie ce message chiffré et vous le déchiffrez donc avec votre partie privée.

Vous voulez lui envoyer un message, vous utilisez sa partie publique, son cadenas. Et là, lui seul possède la clé de son cadenas, donc lui seul peut déchiffrer le message.

Mais, comme je l’ai dit, PGP et GPG utilisent aussi une clé symétrique. Pourquoi ?

GPG utilise une clé symétrique pour gagner en performance. Au moment de chiffrer le message, l’outil génère une clé symétrique. C’est cette clé qui chiffre le message, ce qui est performant. Ensuite, la partie publique de l’algorithme de cryptographie asymétrique chiffre la clé symétrique.

La clé symétrique étant généralement plus petite que le message, il est beaucoup plus rapide pour la partie publique, le cadenas, de chiffrer la clé symétrique que le message.

Grâce à cet outil, la « nezo » (dixit Booba) est effectivement « bien quadrillée » .

Voilà pour PGP et GPG.

Dans les sources se trouvent les liens des outils pour macOS, Windows ou Android.

Bien sûr, on n’a gratté que la surface de ce que ce protocole peut faire. On ira beaucoup plus loin dans un épisode prochain de Cryptotrucs.

Un mot de passe n’est pas sensé être lisible au sein d’un système. On utilise un algorithme cryptographique qu’on appelle un hash pour le stocker de façon illisible.

On parlera de cette technique dans un épisode de Cryptotrucs.

Le but de ce procédé est d’éviter qu’un éventuel hacker puisse récupérer les mots de passe. Cela réduit considérablement les risques de fuites.

Facebook stocke correctement ses mots de passe, semble-t-il. Mais ils ont oublié les logs.

Un log c’est un dispositif qui permet de recueillir des informations sur le comportement d’un système, quel utilisateur s’est connecté, quand, et plus encore.

Il sert souvent à débugger mais peut aussi servir à suivre le comportement des utilisateurs.

La faille elle-même

Dans le cas de Facebook, le log recevait l’information de connexion d’un utilisateur avec son mot de passe lisible.

Jusqu’à janvier dernier (2019), les mots de passe utilisateurs étaient enregistrés en clair dans les logs internes de Facebook.

Il semble que ces mots de passe étaient accessibles à tous les employés Facebook mais pas en dehors. Selon Facebook, du moins.

Facebook dit qu’il n’est pas nécessaire de changer ses mots de passe Facebook et Instagram (Instagram est une filiale de Facebook) mais des experts en cybersécurité disent le contraire.

Ce que j’en dis

Si les mots de passe n’ont pas été récupérés par d’autres que les employés Facebook, alors le risque est minime. Les employés ont de toute façon la possibilité d’ouvrir des sessions au sein de Facebook et Instagram à votre place.

Sauf que

On n’a que la parole de Facebook et ils sont plus que vagues sur ce sujet.

Vous utilisez peut-être le même mot de passe ailleurs (même si ce n’est pas conseillé) et dans ce cas les employés Facebook peuvent y accéder.

Je vous conseille donc de changer vos mots de passe mais aussi d’activer la double authentification pour renforcer la connexion en cas de fuite de mot de passe.

J’ai mis en bas d’article de multiples ressources sur comment faire un bon mot de passe et la double authentification.

Enfin, surveillez vos sessions Facebook et supprimez les sessions que vous ne connaissez pas.

Vous faites ça, à la fois, sur Facebook et sur Instagram.

Sources

• krebsonsecurity
• Un bon mot de passe
• La double authentification

Sources :

• L’espace de noms en xml1.0
• L’espace de noms en xml1.1 et l’impossiblité de passer de http à https
• l’URN

Pour les spécialistes, xml est bien apparu après html. Effectivement, le terme “à l’origine” est mal choisi. Il notait la relation entre xml et html. Je n’allais pas entrer dans les détails des circonvolutions avec sgml, xhtml, etc…

Quelques notions

xml est un langage informatique qui est apparenté à html mais qui est utilisé dans de multiples autres documents (comme le pdf ou un fichier word). html c’est le langage qui permet de visualiser des pages web.

Si on regarde notre page d’accueil Limawi, en cliquant droit avec la souris et en visualisant le code source, on voit le html qui le compose.

Dans la première ligne de cet html, on voit ce qui ressemble à des liens. Ce sont des espaces de noms.

En xml, on peut décrire tout un tas de choses, comme ici un titre de page ou là une image avec ce qu’on appelle une balise.

Pour que le navigateur comprenne que cette balise représente un titre, il lui faut une norme qui lui donne la définition de cette balise.

C’est à ça que servent les espaces de noms. Les liens que vous voyez tout en haut de la page définissent le fonctionnement de certaines balises qui y sont présentes.

Dans cet exemple, les liens que vous voyez définissent les balises qu’on nomme opengraph. Ce sont les balises qui enrichissent votre page dans Facebook, Twitter, et autres.

Avec le xml, on peut aussi mettre un autre document derrière ces liens, en xml lui aussi, qui définit les balises. Un document de définitions.

Ce language xml et ces dérivés comme le html, sont fixés par un organisme que l’on nomme le W3C pour World Wide Web Consortium.

Le problème

Le problème est que le W3C considère ces liens comme essentiellement des identifiants de définition.

C’est à dire que, quelle que soit la page, si on a cet espace de nom en haut de la page on sait qu’on aura les mêmes définitions.

Le W3C permet que ces liens ne mènent pas à un document de définitions et ne soient utilisés que comme identifiants. Le navigateur est sensé connaître déjà le document de définitions et ne suit donc pas le lien.

Ça soulève deux questions.

Question 1

La première, c’est que ça permet l’opacité des définitions. En effet, vous pouvez être poussé à utiliser un domaine de définition comme celui-là pour avoir de beaux liens sur Facebook, sans savoir exactement comment il fonctionne. Cela augmente artificiellement la quantité de travail de documentation et le risque d’erreur comme j’en ai déjà fait l’expérience.

J’ai voulu mettre en place la détection de pages traduites du blog Limawi en me servant de la documentation produite manuellement par les ingénieurs de Facebook. Voyant que ça ne fonctionne pas, j’ai contacté le support Facebook. On passe du temps. Au bout du bout, ils m’annoncent que cette fonctionnalité n’existe plus et qu’ils n’avaient simplement pas mis leur documentation à jour. Que de temps perdu stupidement.

Question 2

La deuxième question est bien plus importante. Ces liens, dans un comportement prévu par xml, peuvent être suivis pour aboutir au document de définitions. Le W3C n’interdit pas cette pratique et encore heureux car c’est une des beautés du xml et une des preuves du génie de Tim Berners-Lee.

By the way, Tim, big fan.

Mais en laissant ce flou sur les propriétés de ces liens, c’est à dire des identifiants de définitions qui peuvent aussi servir de lien vers le document de définitions, le W3C ouvre une faille de sécurité.

Beaucoup de ces liens sont en http. Comme le W3C est très strict sur la syntaxe d’un identifiant, on ne peut pas facilement les changer en https car c’est perçu comme un autre identifiant cassant le fonctionnement des systèmes qui s’y réfèrent.

On peut avoir un hacker qui intercepte le document de définitions dans le cas où un système va le chercher derrière le lien de l’espace de nom. Ce système n’a aucune possibilité de s’assurer que le document qu’il reçoit est le véritable document de définitions. Le hacker peut donc modifier le comportement du système.

À côté de cette façon d’identifier avec des liens, le W3C autorise aussi l’identification par un URN (uniform resource name) qui ne peut pas être confondu avec un lien. L’avantage de l’URN est qu’il n’y a pas d’ambiguïté, on sait que c’est purement un identifiant. Le navigateur doit trouver les définitions par un autre moyen.

D’où ma demande de faire évoluer la norme du W3C. Je comprends, même si je n’adhère pas, qu’on veuille garder pour soi ses définitions mais je voudrais garder le concept de lien vers le fichier de définitions. Ce concept est puissant, offre une flexibilité incroyable, la documentation est dans le code. C’est beau !

Mes propositions

Premièrement, on garde les liens mais ils doivent obligatoirement aboutir à un document de définitions et ne servent plus d’identifiants uniques. C’est le document de définitions qui a cette charge. On peut donc utiliser https au lieu de http et résoudre la faille.

Deuxièmement, on utilise l’URN comme identifiant pur pour les définitions que l’on veut garder opaques.

Ça ouvre des questions plus larges : « Qu’est ce qu’un bon identifiant ? qu’est ce qu’un mauvais identifiant ? ».

Elle est de type CSRF (Cross-Site Request Forgery).

Qu’est ce que c’est ?

Le hacker cache des urls spécifiques dans un site malveillant qui permettent d’effectuer des actions sur le site victime en l’occurrence Facebook.

Le hacker fait en sorte que l’abonné Facebook clique sur ces liens.

Comme c’est l’abonné qui clique le site malveillant utilise les droits de cet abonné pour effectuer des actions rendues possibles par ces urls en utilisant le lien.

Le hacker pouvait accéder à des informations confidentielles voire même les modifier.

Ils pouvait accéder à tout le profil d’un abonné Facebook

En fait, le hacker pouvait même effacer le compte Facebook attaqué.

L’utilisateur Facebook pouvait réduire le risque en activant la double authentification sur son compte Facebook.

Cette faille a été vite comblée et le chercheur qui l’a trouvée a reçu les 25000 dollars prévus par le bug bounty de Facebook.

Sources :

• https://thehackernews.com/2019/02/hack-facebook-account-password.html
• https://www.nextinpact.com/lebrief/38097/7824-facebook-colmate-une-faille-qui-permettait-de-prendre-le-controle-d-un-compte-via-un-simple-lien

mars 14, 2019 18:00:00

Pourquoi à l’ère de l’ « https everywhere », on inclut (même dans les pages qui se vantent d’être sécurisées) des espaces de noms en http ?

mars 14, 2019 18:00:10

En continuant mes développements, j’ai retrouvé ces en-têtes dans des flux RSS (donc en pur xml), et, toujours la même chose, pas de « s ».

mars 14, 2019 18:00:20

J’ai constaté, en suivant ces liens, que je ne tombais, en plus, pas sur des fichiers XSD, des fichiers de définitions xml.

mars 14, 2019 18:00:30

Par exemple, en suivant Purl on tombe sur un beau 404, alors que cet espace de nom est utilisé.

mars 14, 2019 18:00:40

En fait, actuellement, les espaces de noms en xml et html sont utilisés comme des identifiants de définitions que les lecteurs (navigateurs…) de la ressource ont déjà inclus.

mars 14, 2019 18:00:50

Ça me dérange à plusieurs niveaux. Le principe des espaces de noms en xml était de fournir la définition des balises du document directement depuis celui-ci, ce qui permettait une grande flexibilité.

mars 14, 2019 18:01:00

Ce principe est mort. Maintenant, les espaces de noms sont juste des indicateurs de définitions que les lecteurs (navigateurs…) ont inclus dans leurs bases. Comme expliqué ici (en anglais) Stackoverflow

mars 14, 2019 18:01:10

Comme les définitions ne sont même plus accessibles, un nouveau lecteur (navigateur…) ne peut plus apprendre ces définitions facilement et il est obligé de se reposer sur la doc (parfois mal conçue, cf : Opengraph) des fournisseurs de définitions.

mars 14, 2019 18:01:20

Alors qu’avant, une simple mise à jour du XSD permettait au lecteur d’obtenir les nouvelles définitions, maintenant c’est beaucoup moins automatique.

mars 14, 2019 18:01:30

De plus, comme le comportement attendu (en xml) des espaces de noms est de pouvoir être atteints pour donner les définitions, les lecteurs qui respectent la norme xml se trouvent incapables de lire correctement ces fichiers (html, ou RSS, par exemple…)

mars 14, 2019 18:01:40

Bon, il n’y en a plus beaucoup de lecteurs qui respectent la norme complètement, c’est vrai.

mars 14, 2019 18:01:50

Enfin, dans le cas où la ressource est quand même présente, elle est en http et rarement accessible directement. C’est problématique.

mars 14, 2019 18:02:00

Http ne fournit aucune protection contre l’interception éventuelle du XSD et sa modification, ce qui permet à un hacker de modifier le comportement attendu d’un lecteur (navigateur).

mars 14, 2019 18:02:10

Le XSD est parfois précédé d’une jolie page sans moyen automatique d’accéder au fichier de définitions correct. Donc pas d’automatisation possible, ce qui supprime l’avantage des espaces de noms en URI.

mars 14, 2019 18:02:20

Par exemple, la définition xml pour les vidéos chez Google est Google Video sitemap.

mars 14, 2019 18:02:30

Selon la doc, l’espace de nom est en http. Pas de « s ». Doc Google.

mars 14, 2019 18:02:40

Comment, si on respecte la norme xml, on peut être sûr de tomber sur la bonne page en https ? Et ensuite, comment automatiquement accéder au fichier de définitions lui-même qui est Google Video sitemap XSD ?

mars 14, 2019 18:02:50

Et ce n’est pas le seul. En conclusion, le système des espaces de noms xml est complètement cassé à l’heure actuelle ce qui amène à une perte considérable de flexibilité et d’évolution d’usage de la norme.

mars 14, 2019 18:03:00

Et, en plus, quand on respecte la norme, on a un système moins sécurisé (à cause de l’absence de « s »).

mars 14, 2019 18:03:10

On commence à voir que les gestionnaires de paquets feraient mieux de passer en https NextImpact

mars 14, 2019 18:03:20

Il serait bien de se poser la question pour les espaces de noms en URI pour xml et html.

mars 14, 2019 18:03:30

On peut aussi considérer les espaces de noms comme de simples identifiants (ce que je ne souhaite pas) mais dans ce cas, il faudrait pouvoir les identifier autrement que par des URI, ce qui est trompeur.

mars 14, 2019 18:03:40

Vous êtes arrivé au bout du thread, merci. Si vous voulez sécuriser le réseau entre vos appareils, jetez un œil à MyCrypNet.

C’est une énième faille dans le système d’exécution spéculative.

Intel et d’autres concepteurs ont inventé un système qu’on appelle l’exécution spéculative. Cela consiste en gros à calculer en avance les données qui seront potentiellement utilisées à l’avenir et à les stocker dans un coin tout à côté du processeur pour qu’il puisse y accéder très rapidement ça permet de gagner en performance.

les chercheurs ont trouvé un risque qui pourrait aider les hackers à considérablement réduire le temps nécessaire pour leurs attaques.

Dans le cas d’Intel et pour cette faille, qui est la faille SPOIL, on a un souci à cette étape là.

En effet, le processeur quand il vérifie ces données spéculatives, ces données calculées en avance, il ne met pas tout à fait le même temps si ces données sont seules en mémoire ou s’il y a d’autres données avec elle en mémoire.

Le hacker regarde juste la différence de temps entre ces deux cas et si il y a une différence de temps ça veut dire qu’il y a d’autres données dans la mémoire.

Donc c’est à dire que c’est là qu’il faut attaquer. Ça réduit considérablement le temps car au lieu de devoir attaquer toute la mémoire ils savent les points spécifiques où ils peuvent tirer des données.

Ces données étant potentiellement des mots de passe et d’autres informations qui sont censées rester confidentielles.

Intel a répondu qu’on pouvait réduire ce type de faille en faisant des applications qui vérifiaient bien que les données que le processeur leur fournissaient étaient bien celles dont ils avaient besoin.

Sources :

• https://www.developpez.com/actu/249846/L-architecture-de-tous-les-CPU-Intel-remise-en-question-apres-la-decouverte-de-SPOILER-une-nouvelle-faille-difficile-a-corriger-par-voie-logicielle/
• https://www.pcgamer.com/researchers-discover-a-new-spoiler-cpu-flaw-similar-to-spectre-but-intel-isnt-fretting/
• https://appleinsider.com/articles/19/03/05/new-spoiler-vulnerability-in-all-intel-core-processors-exposed-by-researchers
• https://www.zdnet.com/article/all-intel-chips-open-to-new-spoiler-non-spectre-attack-dont-expect-a-quick-fix/

La recherche : https://arxiv.org/pdf/1903.00446.pdf

C’est une attaque DNS.

Alors un DNS c’est quoi ?

Un DNS est un annuaire qui convertit un nom de domaine qui est lisible par un être humain comme par exemple facebook.com en une adresse ip qui est lisible par une machine, par un ordinateur.

L’attaque consiste à faire croire que le nom de domaine que vous visitez (par exemple facebook.com) correspond bien aux serveurs de facebook alors qu’en réalité ce sont les serveurs d’un hacker, d’un attaquant.

Alors, Brian Krebs, un expert en cybersécurité américain, s’est penché sur la question et nous a sorti un rapport.

Au vu de ce rapport les premières attaques datent de février 2017 mais elles se sont amplifiées à partir de décembre 2018.

Elles concernent principalement des acteurs du moyen-orient, des entreprises comme des organismes d’état.

Mais les IPs des hackers sont vraisemblement des IPs européennes, allemandes apparemment.

Donc les attaques en question sont des attaques qui concernent les DNS (les serveurs de noms de domaine) et les registrars.

Les registrars ce sont les entreprises qui enregistrent des noms de domaine pour vous et qui les mettent ensuite publiquement en place.

Par exemple, facebook.com à un registrar qui annonce au monde entier que facebook.com c’est telle IP, telle IP et telle IP.

Les attaques ont eu lieu donc sur ces noms de domaine et sur ces registrars.

Alors on entend partout dans les journaux que ce sont des attaques ultra compliquées et tout.

En fait non, c’est tout simple, c’est le même type d’attaques que quand vous laissez traîner un post-it avec votre mot de passe et que quelqu’un accède à votre ordinateur grâce à ce post-it et ce mot de passe.

En fait les régistrars et les services de noms de domaine n’ont pas mis en place de sécurité d’accès suffisante

Donc le hacker s’est introduit dans les systèmes tout simplement et a changé à sa façon la relation entre les noms de domaine et les IPs correspondantes. Il a mis ses IPs à lui à la place des IPs officielles.

Alors vous vous ne pouvez pas faire grand chose pour contrer cette attaque. C’est le boulot qui revient au registrar, au service de noms de domaine particulier, et eux doivent essayer de renforcer l’authentification sur ces services là pour éviter qu’un hacker pénètre à leur place.

Ils peuvent mettre en place un outil qu’on appelle DNSSEC.

Je parlerai dans un futur article de ce dernier.

Sources :

• https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/
• https://www.mandiant.com/resources/global-dns-hijacking-campaign-dns-record-manipulation-at-scale

Alors qu’est ce que c’est un bug bounty ?

C’est un programme au sein duquel vous pouvez hacker un site ou une infrastructure de façon légale. À condition de respecter certaines règles, celles qui sont donnés par le bug bounty.

Et si vous trouvez des failles de sécurité vous êtes rémunéré. Donc la suisse met en place ce système de vote électronique.

Le projet est soutenu par la poste suisse. Avant même le démarrage du bug bounty, des parties du code source ont fuité sur internet et des experts en cyber sécurité et cryptographie ont donc pu se pencher sur ce code qui a fuité.

Les retours sont mitigés. Les experts ont vu que la qualité du code n’est pas optimale, elle peut être bien meilleur. Le système est extrêmement complexe, dans le sens compliqué du terme, et c’est un peu inquiétant. Car, pour l’instant, beaucoup de projets de vote électronique de par le monde ont échoué dû à la complexité, à la complication et aux failles trouvées tout au long du développement.

Donc ce projet ne part pas sur des bonnes bases. De plus, la poste suisse a du mal à comprendre le concept de code ouvert. Elle a mis en place des règles, concernant ce bug bounty, qui empêchent la divulgation de ces failles et la restitution de ces failles dans leur contexte ce qui est contre-productif. Cela limite énormément la capacité qu’ont les experts de pouvoir étudier ces failles et donc s’en prémunir et améliorer le système.

De ce point de vue, la poste suisse ne comprend pas la loi de Linus, dont je parlerai plus tard, et du second principe de Kerckhoffs dont j’ai déjà parlé dans un épisode (ce sont des principes fondamentaux pour la cryptographie et pour le bon fonctionnement d’un outil d’un système informatique).

Donc c’est un peu bizarre de la voir danser sur ses deux pieds entre le bon système qu’est le bug bounty et la mauvaise façon de faire qui est de vouloir à tout prix cacher son code et éviter qu’ils soit divulgué.

Sources :

• https://www.evoting-blog.ch/en/pages/2019/public-hacker-test-on-swiss-post-s-e-voting-system
• https://www.vice.com/en/article/vbwz94/experts-find-serious-problems-with-switzerlands-online-voting-system-before-public-penetration-test-even-begins
• https://twitter.com/stephanekoch/status/1099241685392019456
• https://www.csoonline.com/article/3269297/online-voting-is-impossible-to-secure-so-why-are-some-governments-using-it.html

En effet, beaucoup de leurs clients les appelaient aimablement pour leur dire que leur gestionnaire de mots de passe ne fonctionnait pas pour certains sites (aimablement tu parles).

Votre gestionnaire de mots de passe, il fonctionne pas pour ces sites là, c’est de la merde

Et donc, ces ingénieurs sont allés voir qu’est ce que c’était que ces sites là. Ce qu’ils ont trouvé est effectivement nouveau.

Regardez cette page, vous voyez le pop-up du social login de facebook.

C’est à dire que les gens quand ils veulent se loguer au site qui est derrière, ils rentrent leur login et leur mot de passe dans ce pop-up de Facebook et ça les loggent avec leur compte facebook sur ce site.

Ouais mais là c’est pas tout à fait le cas.

Vous avez repéré ?

C’est pas le pop-up de Facebook.

Ces infos pop-up, c’est en fait un cadre au sein du site qui imite le pop-up de Facebook mais c’est au sein du site.

C’est à dire que si les gens mettent leur login et leur mot de passe Facebook là dedans c’est le site qui récupère ces mots de passe Facebook.

Et donc des pirates fabriquent des faux sites avec ça pour récupérer login et mot de passe des gens.

Alors comment s’en protéger ?

Et bien, quand vous avez un pop-up Facebook comme ça, essayez de la déplacer dans la fenêtre.

Si vous n’arrivez pas la sortir de la fenêtre c’est que c’est un élément de la page. Et donc c’est pas un pop-up facebook.

Ne rentrez pas votre login et votre mot de passe là-dedans.

Sources :

• Article de Myki : https://myki.com/blog/facebook-login-phishing-campaign/

Les algorithmes testés

AES-256

C’est le standard actuel pour la cryptographie symétrique. AES est l’acronyme de « Advanced Encryption Standard ». Il existe sous 3 variantes, 128, 192 et 256 bits.

Le nombre de combinaisons à tester est donc de

$$ 2^{256} $$

Si vous faites un petit calcul, vous comprenez que la barre de progression restera proche de 0 pendant un certain temps (si on peut qualifier ce temps comme ça).

Un algorithme sur mesure

Le deuxième algorithme est un algorithme imaginaire qui fait 93 bits. C’est la bonne longueur pour voir une progression significative de l’attaque.

Le nombre de combinaisons à tester est donc de

$$ 2^{93} $$

Cet algorithme permet de voir la barre de progression évoluer et arriver à son terme dans un délai raisonnable.

La puissance de calcul employée

Les premiers 27 supercalculateurs du monde de novembre 2018, tirés du top500.

Pourquoi 27 ? Parce que le 28 et 29ème sont étrangement similaires et je n’ai pour l’instant pas la réponse sur le fait de savoir si c’est une erreur ou si ils existent réellement en 2 copies conformes. J’espère une réponse.

Cela fait une puissance de calcul de

$$ 1.001246 \times 10^{18} \text{ flops} $$

(un peu plus d’un exaflop).

L’attaque menée

L’attaque est une brute force pure. Il n’y a pas de tentatives de réductions, de canaux auxiliaires, etc.…

On essaie toutes les combinaisons. Simplement, stupidement.

On considère que c’est un succès quand 50 % des tests sont effectués (50 % de la barre de chargement).

Le point de départ

L’attaque a commencé le premier janvier 2019 à 00:00 UTC (timestamp UNIX : 1546300800).

Sources :

• https://www.top500.org/
• https://www.top500.org/lists/2018/11/

Étape 1, la base

On commence par le début, donc. La toute première étape est le mot de passe, la méthode d’authentification la plus courante.

Qu’est ce qu’un bon mot de passe, comment gérer au mieux la multitude de mots de passe.

Tout sur un bon mot de passe

Pour les développeurs, cet article explique comment gérer l’authentification par mot de passe sur votre système. Attention, les indications de cet article sont valables pour le premier trimestre 2019. Si vous regardez cet article en 2038 (ben bonjour aux transdimensionnels déjà, ou « −··· −−− −· ·−−− −−− ··− ·−· ·−−·− ·−·· ·−−−−· ·· −· − · −· − ·· −−− −· −·· · ·−·· ·− −−· ·−· −−− ··· ··· · ···− −−− ·· −··−  » dans votre langue), les indications seront peut-être (sûrement) obsolètes.

Implémentations de la phrase de passe

Étape 2, on renforce

Une fois le mot de passe au point (donc plus de « 1234567890 »), on passe à la deuxième étape (qui porte bien son nom).

La double authentification relève du principe « Quelque chose qu’on sait, quelque chose qu’on a ».

Tout sur la double authentification

Étape 3, on distribue l’authentification

Une fois authentifié sur un système, pourquoi le refaire sur d’autres. C’est sensible à l’erreur et pas très agréable.

Il existe une solution qui permet de distribuer son authentification en toute sécurité. Avec cette solution, on s’authentifie à un service et les autres services, systèmes, sites web qu’on utilise peuvent reconnaître notre identité et nous authentifier à notre demande sans repasser par les deux premières étapes.

Les social logins, comment ça marche ?

Étape 4, on contrôle l’accès

Une fois authentifié, on n’a pas accès à toutes les ressources fournies par les services non plus. Il y a des règles pour sélectionner ce à quoi on a accès et ce qui nous est refusé. Les utilisateurs d’un service sont organisés selon des groupes ou rôles. Ce que sur les réseaux sociaux on appelle tribu, clan, horde, communauté, comité, section, commission, (·−−· −−− ·−·· −·−− ·−−· ···· −−− −· ·· · ··· pour les transdimensionnels)…

C’est quoi une commu ? Groupes et rôles

Voilà. Bien sûr, c’est une base. Il existe de multiples variantes et cas particuliers.

Le service implémente un contrôle d’accès. Le plus fréquemment, il implémente un contrôle d’accès de groupe ou de rôle. Pour un réseau social, il y a en plus le contrôle d’accès par relations.

Le contrôle d’accès de groupe (group based access control)

C’est la tribu.

Ce contrôle d’accès est un regroupement d’utilisateurs qui ont accès à un certain nombre de ressources.

Ce regroupement défini des permissions (des droits) sur l’usage des ressources. Les utilisateurs de ce groupe héritent chacun de ces permissions.

Le contrôle d’accès de rôle (role based access control)

C’est le chef de tribu, le shaman…

Ce contrôle d’accès définit des permissions (des droits) qui rassemblées toutes ensemble sont données à un utilisateur spécifique.

Généralement, il y a un rôle d’Administrateur qui a tous les droits. Tous les autres rôles sont consentis aux utilisateurs par cet Administrateur. Un utilisateur ne peut pas se donner lui-même un rôle.

Les rôles peuvent être organisés en hiérarchie. Le rôle au dessus englobe toutes les permissions du rôle au dessous et en possède d’autres.

La différence et la relation entre les deux

Quand on compare ces deux types de contrôle d’accès, il peut y avoir des difficultés à les distinguer. Suivant les systèmes, la distinction n’est pas forcément faite.

Mais pour clarifier les choses, je vais tenter d’opérer cette distinction.

Les groupes sont généralement utilisés pour classer les ressources et les utilisateurs. Ils gèrent l’identité. Tel utilisateur appartient à tel ou/et tel groupe.

Les rôles sont généralement utilisés pour gérer les permissions, les droits. Ils gèrent l’activité. Tel utilisateur peut faire ça car il a tel rôle.

Les groupes et les rôles sont liés car complémentaires. Le groupe sert à définir le domaine de compétences du rôle, c’est à dire les utilisateurs et les ressources sur lesquelles le rôle peut agir. Mais un rôle peut être présent sur plusieurs groupes.

Par exemple :

Facebook

Vous pouvez être membre du « groupe des admirateurs de la framboise » et aimer la « page des admirateurs de la mûre ». Du point de vue du contrôle d’accès vous êtes membre de deux groupes.

Au sein du « groupe des admirateurs de la framboise » vous êtes un membre et au sein de la « page des admirateurs de la mûre » vous êtes modérateur. Ce sont vos rôles.

Comme vous le voyez, vos rôles sont délimités par les groupes. Vous êtes modérateur de la « page des admirateurs de la mûre », pas d’autre chose. Mais, il peut y avoir un modérateur du « groupe des admirateurs de la framboise » qui a les mêmes permissions sur ce groupe que vous sur la page. Donc, le rôle peut être présent sur plusieurs groupes.

De même, l’appartenance au groupe vous donne des permissions par défaut. En tant que simple membre du « groupe des admirateurs de la framboise » vous avez accès aux publications de ce groupe. Vous n’y avez pas accès si vous n’êtes pas membre.

Un ordinateur

La séparation entre groupe et rôle est ténue (particulièrement sur UNIX). Mais, on peut définir l’ordinateur comme étant lui-même le groupe et les comptes utilisateurs sur cet ordinateur ont des rôles (généralement un est l’administrateur, rôle présent sur tous les ordinateurs).

MyCrypNet

Un groupe peut être défini :

• Le regroupement de tous les accès MyCrypNet d’un utilisateur ;
• Cet utilisateur ;
• Les autres utilisateurs à qui il a délégué des accès.

Deux rôles peuvent être définis :

• L’utilisateur qui est le propriétaire des accès MyCrypNet tient le rôle d’administrateur ;
• Les utilisateurs délégués forment un deuxième rôle (même si celui-ci peut être redéfini en terme de contrôle d’accès par aptitude).

Contrôle d’accès par relation (relation based access control)

Ce sont vos amis ou contacts sur les réseaux sociaux.

L’existence de la relation entre vous et un de vos « amis » donne des permissions à vous et cet « ami » sur la gestion des ressources de l’un et de l’autre.

La relation gère les permissions. Ces permissions peuvent être symétriques (l’« ami » a autant de droits que vous) ou asymétrique (l’« ami » a moins de permissions que vous, c’est dans ce cas plus une relation de « fan » ou hiérarchique).

Contrôle d’accès par aptitude (capability based access control)

Ce type de contrôle d’accès permet une gestion plus fine des permissions.

Les permissions sont attachées à une ressource (un objet) et non un groupe de ressources (comme dans les contrôles d’accès par groupe ou rôle). L’ensemble objet-permissions forme une aptitude.

Si un utilisateur possède l’aptitude correspondante, il peut accéder à l’objet avec les permissions définies.

Cela permet une gestion des permissions beaucoup plus fine car elle est faite ressource par ressource (objet par objet).

Ce contrôle d’accès est utilisé par Oauth2 (le mécanisme utilisé pour le social login) pour la gestion des permissions. Par exemple, quand vous utilisez le social login Facebook sur un site, Facebook vous prévient que le site voudrait accéder à votre email, votre liste d’amis ou autres.

C’est l’aptitude que vous déléguez ou non (ou en partie) au site sur la ressource Facebook (qui est dans ce cas votre profil).

Chez MyCrypNet, chaque accès MyCrypNet a un certain nombre de permissions associées créées par l’administrateur de l’accès MyCrypNet. L’administrateur délègue alors l’aptitude à un utilisateur. L’utilisateur peut donc gérer l’accès avec les permissions que l’administrateur a défini.

Il y a encore d’autres types de contrôle d’accès que j’évoquerai dans un futur article.

Le protocole de base sur lequel tout repose est Oauth2. On va donc commencer par lui.

Oauth2

Si il y a un 2, ça veut dire que c’est la deuxième version.

La première version, Oauth, présente de multiples failles de sécurité. Ne l’utilisez jamais.

Oauth2 est le protocole qui gère l’autorisation. Il permet à un appareil d’accéder à des ressources, des données présentes sur un serveur.

Pour ça, il utilise des scopes. Ce sont des paramètres qui demandent l’accès à telle ou telle ressource.

Par exemple : le scope « profile » demande l’accès aux informations du profil de l’utilisateur.

Le serveur renvoie un claim. C’est une représentation des données demandées.

Donc pour le scope « profile », on a le claim :

{
  name: Alice le Lapin,
  firstname: Alice,
  lastname: le Lapin
}

Ce protocole peut gèrer différentes méthodes permettant l’autorisation mais dans le cas du social login, une seule nous intéresse.

Octroi d’un code d’autorisation (authorization code grant)

Cette méthode d’authentification permet à un service d’autoriser la connexion d’un utilisateur sans son mot de passe mais en faisant confiance à un serveur d’autorisation.

Voici le fonctionnement :

• l’utilisateur veut se connecter à un service
• le service redirige l’utilisateur vers la page d’accès du serveur d’autorisation
• l’utilisateur se connecte au serveur d’autorisation si ce n’est pas déjà le cas (il utilise son mot de passe à ce moment-là sur le serveur d’autorisation)
• le serveur d’autorisation présente à l’utilisateur le panneau lui demandant confirmation s’il veut réellement se connecter au service
• l’utilisateur confirme
• le serveur redirige alors l’utilisateur vers le service avec un code d’autorisation
• le service utilise le code d’autorisation reçu pour demander un code (token) d’accès au serveur d’autorisation
• le serveur d’autorisation accepte la connexion du service pour l’utilisateur
• l’utilisateur est connecté au service

Comme vous le voyez, l’utilisateur n’a jamais mis son mot de passe dans le service. Le stockage des mots de passe est réalisé uniquement sur le serveur d’autorisation.

OpenID Connect

Cette extension de Oauth2 est gérée par la fondation OpenID. Cette fondation gère aussi l’OpenID original qui a son propre fonctionnement.

Cette extension gère l’authentification (l’identité). Elle se sert du serveur d’autorisation comme serveur d’authentification.

En s’appuyant sur le fonctionnement de l’ « Authorization code grant », elle vérifie l’identité de l’utilisateur auprès du serveur grâce aux informations renvoyées par celui-ci (un identifiant unique, généralement l’email même si le mieux serait un UUID).

De plus, cette extension a des options :

• Le point d’accès UserInfo fourni par le serveur d’authentification : permet de récupérer dynamiquement des informations du profil utilisateur ;
• Le point d’accès Session fourni par le serveur d’authentification : permet de vérifier la session, pour synchroniser les sessions par exemple, faire en sorte que la session de l’utilisateur sur le service se termine en même temps que celle sur le serveur ;
• Un flux de déconnexion qui permet de déconnecter l’utilisateur de tous les services quand il se déconnecte du serveur d’authentification ;
• Un flux de connexion implicite appelé « Single Sign On » qui permet à l’utilisateur de se connecter à un service de façon transparente. Le service et le serveur semblent unifiés dans une seule et même application. Chez Limawi nous avons mis en place un tel système en interne pour le Blog.

Les avantages

Ce système permet de lier des services entre eux sans utiliser de mots de passe pour chacun de ce services (ce qui augmente la sécurité).

De même, cela permet la synchronisation d’informations (données) entre les services en ayant un silo d’informations (un endroit où elles sont stockées) qui fait référence. Cela réduit les conflits d’informations, quand c’est bien fait.

Les risques

Utiliser un tel système requiert d’avoir toute confiance dans le fournisseur d’autorisation. Ce dernier peut avoir accès aux informations au sein des services qui lui sont liés, car il peut se faire passer pour l’utilisateur et obtenir un code d’autorisation à la place de celui-ci.

La synchronisation des identités et des objets (données) n’est pas toujours bien réalisée. On peut se retrouver avec plusieurs comptes sur un même service simplement parce qu’on a changé son email sur le serveur d’autorisation. Le service basé sur l’email ne retrouve plus le compte antérieur et il en crée un nouveau.

La déconnexion n’est souvent pas implémentée. Les grands fournisseurs de social login ayant un fonctionnement de session permanente, beaucoup de services n’implémentent pas de vérification de déconnexion. On peut se retrouver avec des services ouverts (l’utilisateur est connecté) alors que le serveur d’authentification est fermé (l’utilisateur s’est déconnecté de Facebook, Google).

Si le serveur d’autorisation est attaqué, corrompu, fragilisé, tous vos services liés sont fragilisés.

Les attaques

Clickjacking (détournement de clic)

Un hacker peut créer un service malicieux où il charge le serveur d’autorisation dans une iframe transparente.

Pour simplifier, imaginez que votre serveur d’authentification soit un smartphone.

Vous cliquez sur le bouton au milieu de l’écran de votre smartphone pour accepter le service.

Dans le clickjacking, le hacker a glissé une feuille transparente sur l’écran de votre smartphone et quand vous cliquez sur le bouton, vous cliquez en fait sur la feuille, et vous avez accepté sans le savoir l’accès du service malicieux à vos données.

Pour les développeurs, pensez à implémenter le header « X-Frame-Options » et contraignez-le au maximum (« SameOrigin » par exemple) et/ou des framebusting en javascript.

Cross-site request forgery (falsification de requête entre sites)

Un hacker peut faire en sorte que l’utilisateur clique sur un bouton d’autorisation du serveur qui redirige, non pas vers le service que le client souhaite, mais vers le service malicieux du hacker. Le service malicieux récupère le code d’autorisation et redirige l’utilisateur vers le bon service.

L’utilisateur n’a rien vu mais le service malicieux possède le token d’autorisation et donc celui d’accès.

Pour les développeurs, forcez les services à utiliser une url de redirection fixée à l’avance.

Il y a d’autres CSRF (contraction de l’attaque) possibles, j’irai plus en détails dans un futur article.

Confused deputy problem (problème du délégué confus)

C’est le problème qui arrive avec les services qui ne vérifient pas correctement l’identité de l’utilisateur qui utilise le serveur d’autorisation.

Un utilisateur malicieux peut se connecter sur le serveur d’autorisation et faire croire au service que c’est un autre en manipulant l’information que le service utilise pour identifier l’utilisateur.

Si le service n’a pas pris une information fiable pour identifier correctement l’utilisateur, il est trompé et ouvre l’accès au mauvais compte.

Par exemple :

Un service utilise un serveur d’autorisation qui donne un UUID et un nom.

Le serveur d’autorisation a deux comptes :

• Alice avec UUID : 46d07175-dbf2-46e2-80fc-c6493e481479
• Oscar avec UUID : 362b862b-51b3-41f4-82c7-82eb677a9aa4

Le serveur d’autorisation fournit les UUID comme identifiants uniques et s’attend à ce que le service s’en serve.

Mais non, le service choisit d’utiliser le nom comme identifiant unique.

Oscar change donc son nom pour Alice (ce qui est autorisé par le serveur puisque, pour lui, l’identifiant unique est le UUID).

Maintenant, quand Oscar se connecte sur le service il accède directement au compte d’Alice (puisque, pour le service, l’identifiant unique est le nom).

Pour les développeurs, veillez à choisir vraiment un identifiant unique. Les UUID sont faits pour ça. Ils ne transportent pas d’information utilisateur donc ça n’empêche pas un utilisateur de changer toutes les informations qu’il souhaite (même son email).

L’idée avec la double authentification est de faire en sorte que l’utilisateur s’identifie en utilisant deux techniques qui ont très peu de risque d’être piratées en même temps.

La maxime à retenir est :

« Quelque chose qu’on sait, quelque chose qu’on a. »

Concrètement, cela passe souvent par un mot de passe (« quelque chose qu’on sait ») et un élément impliquant un appareil physique (un message sur un smartphone par exemple, « quelque chose qu’on a »).

La double authentification est une méthode parmi un ensemble de méthodes plus large, l’authentification multiple.

Authentification multiple

Quand vous regardez un film d’espionnage avec une base secrète vous avez parfois le héros ou l’ennemi qui passe son œil devant un iris, tape un message sur un clavier, pose sa main sur une tablette, crache de la sal… avant d’ouvrir la porte de la base. C’est ça l’authentification multiple.

Vous pouvez faire, ou avoir affaire à, une chaîne d’authentification, c’est à dire que plusieurs étapes d’authentification sont nécessaires et, quand l’une d’entre elle est refusée, l’authentification est arrêtée.

Dans certains cas réels particuliers où la sécurité est renforcée, on dépasse deux étapes. Mais la plupart du temps, on se contente de deux étapes.

Les façons de faire (ou pas)

SMS

La double authentification la plus fréquente est faite par SMS.

C’est la plus mauvaise méthode car elle est facilement piratable. Si le hackeur a un peu de moyens il peut pénétrer le SS7.

Le SS7 est la couche réseau qui gère l’acheminement des SMS. Cette couche a été conçue dans les années 70 et est donc obsolète depuis longtemps, les standards de sécurité ayant considérablement évolué et des attaques ont eu déjà lieu (voir l’article de NextImpact).

Cette méthode est aussi contraignante quand vous êtes en zone blanche, sans couverture téléphonique.

PUSH

Une autre méthode mise en place par certains services est un push. Cette méthode consiste à faire apparaître sur votre smartphone un message demandant votre validation. Ce message est envoyé (poussé d’où « push » en anglais) par le service sur votre smartphone.

Cette technique nécessite que le smartphone soit connecté sur Internet ce qui peut fragiliser le système car cela offre des capacités d’interception aux hackeurs.

HOTP/TOTP

La deuxième méthode la plus répandue (et utilisée chez Limawi) est la méthode HOTP/TOTP (HMAC based One Time Password, Time based One Time Password).

HOTP, en français « mot de passe unique basé sur un HMAC », est une méthode qui consiste à générer un mot de passe unique basé sur un HMAC (c’est un élément cryptographique qu’on expliquera dans un futur article) qui dispose d’un compteur.

L’utilisateur installe une application sur son smartphone qui génère un message (un token) de 6 caractères à la demande. Ces caractères sont générés grâce à une graine présente sur le compte de l’utilisateur dans le service web et dans l’application elle-même et un compteur qui s’incrémente (qui augmente) de la même façon sur le service web et dans l’application.

Quand l’utilisateur saisit le token issu du calcul généré par l’application dans le service web, ce dernier compare avec le token qu’il a lui-même généré, de son côté, avec le même calcul, et si les tokens sont semblables, cette authentification est bonne. Le service web sait que c’est l’application sur le smartphone de l’utilisateur car c’est le seul appareil qui dispose de la graine de l’utilisateur.

Cette graine est transférée du service web à l’utilisateur, généralement, grâce à un QRCode.

TOTP, en français « mot de passe unique basé sur le temps », est une extension de HOTP où le HMAC est généré à partir de la graine et du temps (un intervalle de temps de plus ou moins 30 secondes). Cette méthode est beaucoup plus utilisée que HOTP.

Je vous conseille l’application FreeOTP pour générer vos tokens sur un smartphone ou d’autres appareils :

• Sur Android et F-droid
• Sur IOS
• Le code source

Ces techniques ne nécessitent pas que votre appareil soit connecté sur Internet ni au réseau SMS téléphone. Les hackeurs ne peuvent pas intercepter de message, parce qu’il n’y a pas de message.

Matériel

Enfin, la méthode la plus sûre d’authentification est d’avoir un matériel dédié. À l’étape d’installation, le matériel est lié à votre compte sur un service web. Grâce à une reconnaissance cryptographique (le matériel contient une clé asymétrique dont on parlera dans un futur article), le service web l’accepte comme « quelque chose que vous avez » dans cette étape d’authentification.

L’inconvénient c’est que cela vous fait un objet en plus à ne pas perdre !

Certaines banques distribuent aussi un matériel à lier avec votre carte bancaire mais le fonctionnement est basé sur TOTP.

Codes de récupération

Cette méthode n’est pas, à proprement parler, « Quelque chose que vous avez ». C’est la meilleure méthode de secours si vous avez perdu, ou vous êtes fait volé, votre matériel ou votre smartphone. C’est une liste de tokens à usage unique que vous pouvez utiliser à la place de votre matériel.

Cachez cette liste dans un endroit sûr, ultra sûr, et ne vous en servez qu’en extrême nécessité.

À l’attaque !!!

Bien sûr, ces solutions ne sont pas parfaites et peuvent être attaquées.

Ingénierie sociale

Dans le cas des SMS, des attaques d’ingénierie sociale ont déjà été mises en œuvre. Par exemple, le cas de DeRay McKesson.

Dans la double authentification par SMS, les hackeurs se font passer pour le possesseur du smartphone auprès de l’opérateur téléphonique et demandent un changement de carte SIM. Leur carte SIM est activée, à la place de celle de la victime, et ils reçoivent tous ses SMS.

Proxy

L’interception par proxy est possible aussi. Celle de l’interception du SMS en créant un faux réseau téléphonique à proximité de la victime (voir l’article de NextImpact), ou plus simplement, un faux site qui se fait passer pour un vrai et qui intercepte toutes les informations envoyées par l’utilisateur (dont le token d’authentification). C’est une attaque homographique sur les noms de domaines internationalisés, ou plus simplement du typosquatting.

Cette méthode peut être contrée avec l’authentification matérielle ou en vérifiant bien le nom de domaine du site web.

Par exemple :

Si vous voulez aller sur « douce-framboise.com », vérifiez que ce n’est pas « douce-framb0ise.com ».

Méthodes de connexions oubliées

Parfois, et cela s’adresse aux mainteneurs de service web, on oublie que la page de connexion n’est pas la seule méthode pour accéder à son compte.

Par exemple, certains services web ne mettent pas de double authentification lors de la récupération d’un mot de passe via un email avec un lien unique.

Un autre exemple, quand vous enregistrez un service externe via une API (comme l’authentification Google ou Facebook par exemple), vous passez par le protocole Oauth2 et parfois la double authentification n’est pas demandée.

Pensez à toutes les méthodes d’accès aux données de vos utilisateurs et optez pour la double authentification, partout.

Règles de mot de passe

Si vous êtes tenté de mettre des règles de mot de passe du genre « entre 8 et 20 caractères » ou « 3 majuscules », arrêtez tout.

Cette façon de procéder est obsolète, hyper rigide pour l’utilisateur et le conduit à créer des mots de passe compliqués pour lui et très faciles à percer pour un Bot.

Vous ne me croyez pas ? Regardez le compte Twitter de passwordistoostrong (en anglais).

Un exemple :

Imaginons la règle :

« entre 8 et 20 caractères, au moins 3 majuscules et un signe de ponctuation. »

Ce mot de passe correspond : « AbCdEfgh! » bien qu’il ne puisse pas être considéré comme fort.

Par contre, l’utilisateur peut être frustré.

Entropie

Utilisez plutôt un système basé sur l’entropie.

La bibliothèque zxcvbn (ce sont les lettres de la ligne du bas d’un clavier américain) est une bonne implémentation du calcul de la force d’un mot de passe par entropie. Elle est accessible dans une grande variété de langages informatiques. C’est celle que nous utilisons chez Limawi.

L’avantage est qu’il n’y a plus de règles rigides pour l’estimation de la force du mot de passe. La bibliothèque calcule la complexité de votre mot de passe (en prenant en compte la rareté des lettres, de leurs agencements, etc.) et lui donne une note. Vous pouvez ensuite définir à partir de quelle note, quel cap, vous considérez le mot de passe entré comme suffisamment sûr.

Vous devez, bien sûr, avoir les mêmes notes, les mêmes caps, côté serveur et côté client. En cas de différence, c’est le serveur qui a le dernier mot car le côté client peut être trafiqué par un hackeur (son environnement n’est pas sûr).

Éviter les mots de passe percés

Une fois que vous avez mis un cap pour éviter les mots de passe faibles, il faut quand même vérifier si le mot de passe saisi n’est pas un mot de passe qui a déjà été percé.

Cette étape est une sécurité supplémentaire optionnelle car si le cap de complexité est assez haut, la façon dont le mot de passe est stocké peut contrer les attaques arc-en-ciel de façon relativement efficace. Mais c’est quand même un bonus.

Pour cela, on peut charger un fichier javascript côté client ou faire une requête ajax sur une API quand l’utilisateur crée son mot de passe.

Si votre requête Ajax envoie le texte en clair, c’est problématique, car vous offrez une surface d’attaque supplémentaire aux hackeurs.

Le fichier javascript chargé est lourd et il vaut mieux le charger en asynchrone. Mais, même en asynchrone, la taille du fichier (et donc le nombre de mots de passe) ne peut pas être élevé.

Bien sûr, le côté client n’étant pas sûr, il faut réitérer l’opération côté serveur.

Une autre technique consiste à utiliser le service Have I Been Pwned. Il offre une solution élégante d’un point de vue technique mais étant de droit australien et reposant sur des services américains, il pose une sérieuse question concernant le respect du RGPD européen (voir dans un futur article sur notre site).

Ce service fonctionne grâce au k-knowledge (connaissance-k ?).

Vous hachez le mot de passe saisi par l’utilisateur et vous envoyez au service les k premières lettres de ce hash. Le service vous renvoie tout les hashes de sa base de données qui ont ces k premières lettres. Vous comparez avec le hash du mot de passe de l’utilisateur et, si un des hashes du service correspond, alors c’est que le mot de passe est percé.

Exemple :

le mot de passe « framboise » a pour hash SHA256 :

« F9E4141EE43A3B877758E2584A1F6A0E7A9C8D6E58BB859A1665D8C1F447003C »

les 5 premières lettres sont « F9E41 ».

Vous envoyez ces 5 lettres à Have I Been Pwned.

Il renvoie :

• « F9E4141EE43A3B8777ERT8584A1F6A0E7A9C8D6E58BB859A1665D8C1F447003C »
• « F9E4141EE962758777ERT8584A1F6A0E7A9C8D6E58BB859A1665D8C1F447003C »
• « F9E4141EE43A3B877758E2584A1F6A0E7A9C8D6E58BB859A1665D8C1F447003C »

Vous comparez et vous vous rendez compte que le troisième hash est le même que celui du mot de passe. Le mot de passe est donc percé.

Avec ce système, aucun mot de passe ne circule sur le réseau et Have I Been Pwned ne sait pas quel mot de passe vous avez testés. Pour l’exemple, trois résultats ont été renvoyés mais plus k est petit, plus le nombre de résultats renvoyé est grand.

Puis stocker vos mots de passe

Ensuite, une fois que l’utilisateur a trouvé un bon mot de passe, il vous l’envoie (de façon sécurisée) et vous devez le stocker.

Alors, une règle tout à fait fondamentale : ne stockez jamais un mot de passe en clair. Si un hackeur réussit à accéder à votre stock de mots de passe, vous lui avez servi, sur un plateau, l’accès à la totalité des comptes sur votre service et à d’autres services (les utilisateurs réutilisent souvent malheureusement le même mot de passe sur des services différents).

Alors comment faire ?

1. Tout d’abord, il faut que vous limitiez la longueur du mot de passe mais pas trop. Drupal, par exemple, limite la longueur a 512 octets, c’est à dire entre 512 et 128 caractères en UTF-8. Cette étape est nécessaire pour éviter une attaque DOS car l’étape de hash demande un peu de ressource machine (on saisit un énorme mot de passe de plusieurs milliers de caractères qui bloque la machine à l’étape de hash.).

2. Ensuite, vous générez aléatoirement un sel (sel de table appelé plus communément poivre ou sel de ligne ?). C’est à dire une chaîne d’un nombre précis de caractères.

   

   Vous pouvez le générer au niveau de votre stock (c’est à dire pour tout le stock) ou au niveau du mot de passe (un par mot de passe). Il sera ajouté au mot de passe pour rendre deux mêmes mots de passe différents. Le sel sert à empêcher les comparaisons de hash, table par table ou ligne par ligne, si un utilisateur a utilisé le même mot de passe sur plusieurs services différents ou si deux utilisateurs ont choisi le même mot de passe.

   Exemple :

   Avec un sel par table :

   Alice a mis le mot de passe « framboise » dans le site « gentilles-framboises-aplaties.com » et dans le site « méchantes-framboises-aplaties.com ».

   Le site « gentilles-framboises-aplaties.com » génère le sel « 458 », le mot de passe de Alice sera donc « 458framboise ».

   Le site « méchantes-framboises-aplaties.com » génère le sel « gdf », le mot de passe de Alice sera donc « gdfframboise ».

   Si un hackeur réussit à capturer les deux tables, il ne pourra pas comparer les hashs des mots de passe car ils seront différents (puisque les mots de passe sont différents). Il ne saura pas que Alice a mis le même mot de passe sur les deux services.

   Avec un sel par ligne :

   Alice a mis le mot de passe « framboise » dans le site « gentilles-framboises-aplaties.com », Bob a mis aussi le mot de passe « framboise » dans le même site.

   Le site « gentilles-framboises-aplaties.com » génère le sel « 458 » pour le mot de passe d’Alice, le mot de passe de Alice sera donc « 458framboise ».

   Le même site génère le sel « sdd » pour le mot de passe de Bob, le mot de passe de Bob sera donc « sddframboise ».

   Dans ce cas, un hackeur qui réussit à avoir la table du site « gentilles-framboises-aplaties.com » ne pourra pas comparer le hash de Bob et celui d’Alice. Il ne saura pas que c’est, en fait, le même mot de passe.

3. Ensuite vous hachez votre chaîne de caractères composée du sel et du mot de passe. Utilisez un algorithme sûr comme BCRYPT, SCRYPT ou argon2, SHA512 n’est plus considéré sûr.

   Le hash résultant pour le mot de passe « framboise » et le sel « 458 » est :

   hash(sha256, ‘458framboise’) = ‘527D88733ED03CE5EF2D12AE4279950ABC29DC42817B14A58AB2150678A7CC72486CE637B8AD10333E80879F3D0CE685FA6CBB5DB8D7954382C2116616F8F6CF’

4. Vous avez déjà un mot de passe a peu prés sécurisé stocké. N’oubliez pas de stocker aussi le sel. Vous pouvez renforcer le hash en répétant la dernière étape avec le hash précédant, à la place du sel :

   hash(sha256, ‘527D88733ED03CE5EF2D12AE4279950ABC29DC42817B14A58AB2150678A7CC72486CE637B8AD10333E80879F3D0CE685FA6CBB5DB8D7954382C2116616F8F6CF framboise’) = ‘E3A252D3C455D638C82D8430DDC85E9B5B13F6508D690D97E2C5A1CC8AEE4A26D4C723E4EE4F524B4926C0357B2651132DF67446721BB4D3BCDD017C4A0E0E1B’

   Le but est d’éloigner le hash résultant de possibles hashes déjà connus par les hackeurs. Il faut que ce soit compliqué pour eux de retrouver le mot de passe.

   Une fois votre mot de passe stocké, quand l’utilisateur veut se reconnecter, votre système refait les mêmes étapes (en utilisant le sel déjà existant) et compare le résultat obtenu avec le hash déjà présent dans le stockage. Si ce sont les mêmes, c’est le bon mot de passe.

Les erreurs à éviter

Des fois, on fait des erreurs tellement bêtes ! En voici quelques unes à éviter.

Quand vous changez le cap de complexité des mots de passe acceptés, ne mettez pas ce seuil dans les champs d’anciens mots de passe. Sinon l’utilisateur ne pourra plus saisir son ancien mot de passe pour le changer. Mettez le cap de complexité uniquement sur les champs de nouveaux mots de passe.

Si vous changez la façon dont vous stockez vos mots de passe ou la complexité et vous avez besoin que l’utilisateur agisse, signalez le lui par email. N’envoyez pas de récupération de mot de passe avec lien unique, l’utilisateur peut très bien le lire des mois après, le temps pour un attaquant de l’utiliser.

N’envoyez, bien sûr, jamais le mot de passe d’un utilisateur par email. Retenez que les emails sont comme des cartes postales : tout le monde peut les lire. Et si vous arrivez à envoyer son mot de passe à un utilisateur, cela veut dire que vous ne le stockez pas correctement.

Faites des messages d’erreur signifiants quand l’utilisateur crée un nouveau mot de passe. Donnez des valeurs comme « faible, fort, très fort » et pas des notes d’entropies incompréhensibles.

Bien sûr, assurez-vous que le mot de passe est bien envoyé via une connexion https. Bannissez http de votre système.

Pour allez plus loin, faites des chaînes d’authentification. C’est à dire de la double authentification avec un token sur un smartphone par exemple, en plus du mot de passe.

Le mot de passe pour les gouverner tous

Tout d’abord, comment faire un bon mot de passe qu’on puisse se rappeler ?

Remplacer les signes, c’est pas bien

Souvent, une fausse bonne idée ressort. Celle de remplacer des signes par d’autres.

Comme par exemple, utiliser « mot de p@sse » au lieu de « mot de passe ».

Cette idée vient du monde anglophone et part du fait que la plupart des mots de passe étaient composés de caractères de la table ASCII, c’est à dire des 26 lettres de l’alphabet latin plus quelques signes de ponctuations.

Cet article est rédigé en français et, donc, s’adresse à des francophones qui sont moins concernés par ce problème car le français contient des signes qui ne sont pas inclus dans la table ASCII de base. Les accents par exemple « à, é, è, ù… » sont inclus dans la table ASCII étendue, voire l’UTF-8 (une table qui contient tous les alphabets du monde : arabe, cyrillique, chinois…).

Cette technique donne des mots de passe beaucoup plus difficiles à mémoriser. Ayant du mal à les mémoriser, on a tendance à les faire assez courts, ce qui est aussi très mauvais.

La phrase de passe, c’est bien

Cette technique est connue grâce au comicstrip de xkcd souvent appelée « correct horse battery staple ».

Pour que cela soit efficace, il faut que la combinaison de mots soit la plus rare possible. Dans le comicstrip de xkcd, la rareté des combinaisons est évoquée par le caractère aléatoire.

Mais n’oublions pas que c’est un mot de passe à mémoriser. Nos cerveaux gèrent mal le caractère aléatoire. C’est pour ça qu’en fin du comicstrip, l’auteur insiste sur l’idée de se faire une image mentale de la phrase de passe.

En français, la fréquence des mots et de leurs combinaisons est moins élevée qu’en anglais car les utilisateurs francophones sont moins nombreux et le français contient des articles, déterminants, possessifs qui diminuent encore la probabilité d’apparition des combinaisons. La nécessité de l’aléatoire est moins forte qu’en anglais.

On peut donc utiliser des phrases de passe qui soient grammaticalement correctes comme mot de passe.

Un exemple pour illustrer tout ça :

À votre avis, quel est le meilleur mot de passe :

« !Es_fr@mbo1ses »

ou

« L’Air de la reine de la nuit, la Flûte enchantée de Wolfgang Amadeus Mozart »

Si vous aimez Mozart, c’est certainement le deuxième. Il est facile à retenir, plus long que le premier et la possibilité que deux personnes aient ce même mot de passe est faible. De plus, il a des majuscules, une virgule, une apostrophe, un « û » et un « é ».

Le gestionnaire de mots de passe pour les amener tous

Avoir un mot de passe dont on puisse se rappeler, c’est bien. Mais ce qui est mieux encore c’est de pouvoir utiliser des mots de passe dont on ne puisse pas se rappeler (même soi-même). Cela diminue les risques de les divulguer, sans s’en rendre compte, au détour d’une conversation.

Jimmy Kimmel en fait un passage de son émission, disponible sur Youtube, en anglais.

Donc pour éviter ce risque, pour faire des mots de passe dont on ne se rappelle pas, il faut utiliser un gestionnaire de mots de passe.

C’est un logiciel ou un service web qui stocke les mots de passe et vous les affiche quand vous les lui demandez. Vous n’avez plus qu’à les copier-coller, ou utiliser des plugins qui le font pour vous, dans les pages de connexion. Il est la plupart du temps chiffré et on y accède donc avec un mot de passe maître, le seul dont vous devez vraiment vous rappeler.

Avec ce système, comme vous n’avez pas besoin de vous souvenir de vos mots de passe, allez-y à fond. Faites des mots de passe à 50 caractères générés aléatoirement avec pleins de signes bizarres. Utilisez l’UTF-8 en regardant la compatibilité de vos logiciels et services web (ils ne sont pas tous compatibles, ils n’affichent pas tous correctement l’alphabet cyrillique par exemple).

Logiciel ou service web

L’avantage du logiciel par rapport au service web, c’est que le risque d’attaque et de fuites est diminué.

Un service web de gestion de mots de passe attire les attaquants car le gain en cas de faille est plus important que le gain en cas de faille de votre logiciel (des milliers de comptes au lieu d’un).

Il y a aussi des conflits de droits entre les utilisateurs du service et l’environnement juridique du service. Par exemple, le RGPD européen et le Cloud Act américain. On reviendra sur ces notions de droits dans de futurs articles.

L’avantage d’un service web est que, normalement, le risque de perte des mots de passe est plus faible et il bénéficie d’une équipe à plein temps pour repérer les failles et y remédier.

Et chez Limawi

Chez Limawi, nous utilisons le logiciel KeepassXC.

Il a l’avantage d’être opensource, donc le code peut être audité facilement.

Il est présent sur vos appareils et non en ligne, ce qui réduit les possibilités d’attaque sur des services centralisés.

Il chiffre les mots de passe avec le mot de passe maître.

Les conflits de droits possibles entre RGPD européen et Cloud Act américain sont évités, les mots de passe n’étant pas stockés sur des serveurs américains.

Il est, par contre, plus compliqué de partager le gestionnaire de mots de passe entre appareils. De plus, vous devez organiser vous-même le backup de votre base chiffrée de mots de passe.

keepassXC est une variante de KeepassX (dont le développement semble arrêté), lui-même une variante de Keepass qui n’est disponible que pour Windows. D’ailleurs, Keepass fera l’objet d’un audit de sécurité par la commission européenne.

Et dans les ténèbres les lier (les attaques en gros)

Les attaques de masse

Les attaques de masse visent à récupérer le plus grand nombre de mots de passe possible sans se soucier des personnes à qui ils appartiennent.

Dictionnaire

Les attaques les plus fréquentes de ce type sont les attaques par dictionnaire. Ce sont celles qui demandent le moins de capacité de calcul mais le plus de capacité de stockage (le compromis temps-mémoire). En effet, on teste les mots de passe connus les plus courants (provenant des attaques déjà réussies) et si ça passe pas on passe au compte suivant.

Une liste des mots de passe les plus courants est publiée chaque année dans l’espoir de modifier les comportements de gens mais, malheureusement, il n’y a pas d’évolution sensible.

Voici la liste des 25 mots de passe les plus utilisés de 2018, faite par Splashdata, avec, entre parenthèses, la comparaison de 2017 :

• 123456 (position non changée)
• password (position non changée)
• 123456789 (a pris 3 places)
• 12345678 (a perdu 1 place)
• 12345 (position non changée)
• 111111 (nouveau)
• 1234567 (a pris 1 place)
• sunshine (nouveau)
• qwerty (a perdu 5 places)
• iloveyou (position non changée)
• princess (nouveau)
• admin (a perdu 1 place)
• welcome (a perdu 1 place)
• 666666 (nouveau)
• abc123 (position non changée)
• football (a perdu 7 places)
• 123123 (position non changée)
• monkey (a perdu 5 places)
• 654321 (nouveau)
• !@#$%^&* (nouveau)
• charlie (nouveau)
• aa123456 (nouveau)
• donald (nouveau)
• password1 (nouveau)
• qwerty123 (nouveau)

Le problème de cette liste, présente dans tous les articles sur « comment faire un bon mot de passe », c’est qu’elle vient du monde anglophone et ne reflète pas les mots de passe les plus fréquents de monde francophone. Si vous avez des sources pour les mots de passe francophones, je suis intéressé.

Bien sûr, il circule sur le Web des listes avec 100, 1000, 10000, 1 million, voire plus, de mots de passe.

Arc-en-ciel

Le deuxième type d’attaques est l’attaque par table arc-en-ciel (« rainbow table »). Elle est plus coûteuse en termes de calculs mais demande moins de capacité de stockage. Elle demande néanmoins que le tableau des hashes (c’est à dire le mot de passe chiffré, on parlera du « hash » dans un futur article) soit récupéré en hackant le service web, logiciel.

La table arc-en-ciel compare les hashes qu’elle a avec ceux du tableau hacké. Si les hashes correspondent, ça veut dire que c’est le même mot de passe.

Exemple :

L’attaquant a une table arc-en-ciel avec un mot de passe et son hash en md5 (c’est un type de hash, à ne jamais utiliser en vrai) :

• password : 5f4dcc3b5aa765d61d8327deb882cf99
• sdhfksdkfh : e2a1dbf388e7a7e87dc02943e3521036
• framboise : 54a9fc48a5b664772e2ca06d1e0772d9

Il a hacké un tableau de hashs sur un site et a la liste suivante de noms et hashs :

• Bob : 098f6bcd4621d373cade4e832627b4f6
• Alice : 54a9fc48a5b664772e2ca06d1e0772d9
• Lee : 190a16e29799b184d9900690ee04438a

Il voit que le deuxième hash de la liste correspond au troisième hash de sa table arc-en-ciel. Donc il sait que le mot de passe d’Alice est « framboise ».

Ces deux types d’attaques peuvent être contrés par la technique de la phrase de passe. Si la phrase de passe n’est pas dans la liste des mots de passe ou celle des hashs, alors ces attaques ne peuvent rien.

Dans un prochain article, on verra des techniques pour renforcer cette table de hashs si vous concevez votre site web.

Dans l’article sur le hash, on verra aussi comment réduire le besoin de stockage des tables arc-en-ciel.

Force brute (groumfff)

La dernière technique est celle de la force brute. On essaie toutes les combinaisons possibles. C’est la plus coûteuse en termes de calculs mais la moins coûteuse en termes de stockage.

Cette technique est la plus ancienne et c’est elle qui est à l’origine de l’idée de mettre des signes particuliers dans les mots de passe.

En effet, si l’attaquant utilise uniquement l’ASCII classique (c’est à dire l’alphabet latin plus des signes de ponctuations), avec les signes particuliers on est tranquille.

Mais, cela fait longtemps que les attaquants utilisent l’ASCII étendu (avec les majuscules et les accents) ou l’UTF-8 (tous les alphabets du monde : arabe, cyrillique, chinois…) pour tester tous les choix.

On contre cette technique en faisant des phrases de passe plus longues et bien sûr en utilisant l’alphabet complet (pas de « aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa »).

Cela augmente l’entropie (on expliquera ce qu’est l’entropie dans un prochain article) de votre mot de passe. Le français ayant des signes (lettres avec accents) en plus de l’anglais, l’entropie monte aussi grâce à eux.

Exemple :

« !Es_fr@mbo1ses » a une entropie de 72,1 bits ce qui le place comme fort (c’est pas mal pour la plupart des cas)

et

« L’Air de la reine de la nuit, la Flûte enchantée de Wolfgang Amadeus Mozart » a une entropie de 475,8 bits ce qui le place comme ultra-fort (inutile de préciser si c’est pas mal).

Plus l’entropie est grande, plus l’attaque prend de temps. Et le but c’est de faire perdre du temps à l’attaquant (pas en secondes, mais en années ou en siècles). Et bien sûr, avec le gestionnaire de mots de passe, profitez-en. Utilisez l’UTF-8 en prenant garde à la compatibilité.

L’attaque ciblée

L’attaque ciblée consiste à essayer de hacker un utilisateur spécifique.

Keylogger

Cette technique consiste à infecter l’appareil de l’utilisateur avec un outil qui récupère toutes les touches du clavier que l’utilisateur utilise. Donc si l’utilisateur tape son mot de passe, celui-ci est récupéré par l’outil.

Ce dispositif et le moyen de s’en défendre, sont en hors le sujet de cet article et ils seront le thème de plusieurs autres articles.

Ingénierie sociale

Par de l’ingénierie sociale, le hackeur peut récupérer votre mot de passe auprès de vos amis, votre famille ou vous-mêmes. Rappelez-vous, Jimmy Kimmel en anglais.

Tout d’abord, j’insiste. Ne partagez jamais votre mot de passe avec qui que ce soit. Beaucoup de services (y compris les emails) ont des outils pour partager des comptes sans partager des mots de passe.

Ensuite, c’est là que le gestionnaire de mots de passe intervient. Si vous-même ne connaissez pas votre mot de passe, le hackeur ne pourra pas le retrouver par cette technique.

Pour votre mot de passe maître, essayez des combinaisons de mots, une phrase que personne ne connaît.

Des outils pour les trouver

Oui, je sais. Pour ceux qui ont compris la référence dans les titres, j’ai du inverser des titres pour la cohérence de l’article.

Enfin, une fois que vous avez des mots de passe dans des services en ligne ou des appareils, il faut les surveiller, suivre leur cycle de vie.

Il faut vous assurer que votre mot de passe supprimé l’est réellement.

Durée de vie

Vous pouvez mettre une durée de vie à votre mot de passe. Je déconseille cette technique si vous n’êtes pas sûr de votre coup car cela va souvent à l’encontre du comportement naturel humain.

En effet, rapidement, vous mettez des mots de passe très peu différents des précédents ou vous ne les changez plus. Le comportement du service web, logiciel en cas de non renouvellement du mot de passe n’étant pas standardisé, des failles de sécurité peuvent apparaître.

Veille de failles

Il faut vous assurer aussi que votre mot de passe n’a pas été piraté. Dans ce cas, mettez en place des veilles.

Un bon service existe pour ça, il s’agit de haveibeenpwned de Troy Hunt. Vous pouvez faire une veille sur vos adresses email et si elles apparaissent dans des failles, le service vous le signale.

Ce service a même des outils pour l’intégrer dans votre site web/logiciel. Cependant, j’ai de sérieuses interrogations concernant le respect du RGPD (à voir dans un futur article).

Enfin, voici un compte Twitter à suivre en anglais, qui montre encore les difficultés à faire comprendre aux services web, logiciels, le bon fonctionnement des mots de passe :

https://twitter.com/PWTooStrong

Bon, j’ai annoncé pleins de futurs articles. Super, je me suis ajouté du boulot. Pfff…

Pour les développeurs, voici quelques conseils pour implémenter vos mots de passe.

Le masque jetable est un chiffrement qui a été inventé par Gilbert Vernam, un ingénieur américain de AT&T Bell Labs, en 1917.

Le nom « masque jetable » est la transcription française du terme originel américain « One time Pad » (OTP), la traduction mot à mot étant « tampon à usage unique » (pas de jeu de mots pourris, s’il vous plaît).

Il est basé sur une technique de chiffrement beaucoup plus ancienne appelée «  le chiffre de Vigenère ».

Le masque jetable a encore été perfectionné par le général américain Joseph Mauborgne, qui inclut le caractère aléatoire de la clé de chiffrement.

Il consiste à chiffrer un message avec une clé en additionnant la clé au message, élément par élément. La clé ne doit être utilisée qu’une seule fois (d’où le jetable). Pour déchiffrer, on soustrait la clé au message.

Bon, l’histoire c’est bien mais dans les faits, comment ça marche ?

Fonctionnement

Pour pouvoir comprendre le masque jetable il faut déjà maîtriser (ou du moins comprendre) la congruence (ou modulo).

La base

On va commencer en utilisant des textes non aléatoires pour les clés. Attention, c’est juste histoire de démarrer doucement parce que là on est 0 au niveau sécurité.

On va prendre un texte de Bigflo&Oli comme message que l’on veut chiffrer et un texte de Georges Brassens comme clé.

Le message est tiré de « Alors alors » :

« Alors alors, On devait faire le tour de la Terre »

La clé est tirée de « Bancs publics » :

« Les gens qui voient de travers pensent que les bancs verts »

Vous avez le modulo en tête ? Bon, on va commencer par affecter un nombre à chaque lettre de notre alphabet :

A=0, B=1, C=2, D=3, E=4, F=5, G=6, H=7, I=8, J=9, K=10, L=11, M=12, N=13, O=14, P=15, Q=16, R=17, S=18, T=19, U=20, V=21, W=22, X=23, Y=24, Z=25

Donc, pour notre alphabet de 26 lettres on a les 26 premiers chiffres.

Chiffrement

Pour chiffrer, c’est simple, on additionne les lettres face à face. « Additionner des lettres, mais t’es perché ? » me direz vous, mais c’est pour ça qu’on leur a donné un équivalent en nombre, faut suivre un peu. Comme on n’a pas affecté de valeur à la virgule, on va l’enlever.

Allez, c’est parti :

« Alors alors On devait faire le tour de la Terre »

+

« Les gens qui voient de travers pensent que les bancs verts »

Le « A » de « Alors » + le « L » de « Les » = A + L = 0 + 11 = 11 = L

Ensuite le « l » + le « e » = l + e = 11 + 4 = 15 = p

Donc, petit à petit :

« Alors alors On devait faire le tour de la Terre »

+ + +

« Les gens qui voient de travers pensent que les bancs verts »

= = =

0 11 14

+ + +

11 4 18

= = =

11 15 32

= = =

L p ?

Effectivement pour l’addition de « o » et « s », on trouve 14 + 18 = 32 et là on a un soucis, on a pas de lettre avec une valeur de 32.

Mais, rappelez vous, la congruence (le modulo, tout ça, tout ça).

Vu qu’on a que 26 lettres, on va utiliser un modulo 26, histoire de rester dans ces valeurs.

Un petit coup de modulo 26 sur 32, ça fait

$$ 32 \pmod{26} \equiv 32 -26 \pmod{26} \equiv 6 \pmod{26} $$

Et 6, on a, c’est la lettre G.

Du coup, on peut finir notre calcul :

« Alors alors On devait faire le tour de la Terre »

+ + + ...

« Les gens qui voient de travers pensent que les bancs verts »

= = =

0 11 14

+ + +

11 4 18

= = =

11 15 32 mod(26)≡ 6 mod(26)

= = =

L p g …

Au final :

« Alors alors On devait faire le tour de la Terre »

+

« Les gens qui voient de travers pensent que les bancs verts »

=

« Lpgxw ndela Jb liitlx yrimi cw ishj hr eq Nicvw »

On a notre message chiffré.

Déchiffrement

Du coup, pour déchiffrer, on fait le contraire, on soustrait la clé au message chiffré.

On a le message chiffré « Lpgxw ndela Jb liitlx yrimi cw ishj hr eq Nicvw » et la clé « Les gens qui voient de travers pensent que les bancs verts ».

Donc :

« Lpgxw ndela Jb liitlx yrimi cw ishj hr eq Nicvw »

- - -

« Les gens qui voient de travers pensent que les bancs verts »

= = =

11 15 6

- - -

11 4 18

= = =

0 11 -12

= = =

A l ?

Donc, même problème qu’au chiffrement, on a pas de lettre qui corresponde à -12.

On applique le modulo 26 :

$$ -12 \pmod{26} \equiv -12 + 26 \pmod{26} \equiv 14 \pmod{26} \equiv o $$

On continue le calcul et on retrouve :

« Lpgxw ndela Jb liitlx yrimi cw ishj hr eq Nicvw »

- - - ...

« Les gens qui voient de travers pensent que les bancs verts »

=

« Alors alors On devait faire le tour de la Terre »

Mauborgne est dans la place

Bon, ça c’est bien joli, mais c’est pas très sûr. Pour renforcer la sécurité on va écouter le général Mauborgne et utiliser une clé aléatoire (ou du moins plus aléatoire).

Après avoir mis un générateur pseudo-aléatoire (oui, je sais, un terme incompréhensible, on y reviendra dans un article futur) dans mon ordinateur, roulé ma tête sur le clavier et fait marcher le chat dessus pour générer de l’entropie (oui, un autre terme incompréhensible), j’obtiens la clé suivante :

« snchfzrhqjlnveivpyonrkudrpqtpxptfwrildof »

On va chiffrer le message suivant, toujours de Bigflo&Oli, extrait de « Dommage » :

« Il croisait cette même fille, avec son doux parfum »

Chiffrement

Et c’est reparti :

« Il croisait cette même fille, avec son doux parfum »

+ +

« snchfzrhqjlnveivpyonrkudrpqtpxptfwrildof »

= =

8 11

+ +

18 13

≡ =

0 mod(26) 24

=

a y …

On arrive au message chiffré suivant :

« Il croisait cette même fille, avec son doux parfum »

+

« snchfzrhqjlnveivpyonrkudrpqtpxptfwrildof »

=

« ayeythjhycnroxmhtksszvfhrkuvhlcwtqoxlutze »

Déchiffrement

Je crois qu’à ce stade vous avez compris. Un petit exemple alors.

Toujours avec notre modulo(26), déchiffrez ce message :

« irszlg k wiu ladw »

avec la clé :

« xjgzpyisqbjmplcxhwfpijqrstghighnhylshqza »

Et tweetez, postez le résultat.

Le Che level

Bon, jusqu’à présent on était dans le mignon, maintenant on attaque le dur.

Che Guevara et Fidel Castro communiquaient avec une technique de cryptographie basée sur le masque jetable. Cependant, il y avait une petite complexité supplémentaire.

Ils n’utilisaient pas une suite de nombres comme nous l’avons fait, mais ils avaient affecté des nombres arbitrairement aux lettres de l’alphabet.

Voici leur substitution :

A=6, B=38, C=32, D=4, E=8, F=30, G=36, H=34, I=39, J=31, K=78, L=72, M=70, N=76, O=9, P=79, Q=71, R=58, S=2, T=0, U=52, V=50, W=56, X=54, Y=1, Z=59

Vous allez me dire « mais comment on fait une congruence avec ça ? », attendez un peu, ça vient.

En fait, ils ne transmettaient pas des lettres mais des chiffres et la clé était elle-même composée de chiffres. Ils utilisaient le modulo le plus connu (celui qu’on utilise sans savoir), le modulo 10.

Alors, comment faisaient-ils ? On va prendre un exemple.

Chiffrement

On veut chiffrer le message suivant :

« J’aime pas les framboises » (c’est un exemple, moi j’aime bien les framboises)

On remplace les lettres pas leur nombres :

« J A I M E P A S L E S F R A M B O I S E S » devient « 31 6 39 70 8 79 6 2 72 8 2 30 58 6 70 38 9 39 2 8 2 »

On va chiffrer ce message avec la clé :

« 4317892093088287991744997181628757157172 »

Pour ça, on additionne les chiffres face à face et on applique le modulo 10. Pour se faciliter la tâche, ils regroupaient d’abord les chiffres par paquet de 5.

Donc, le message :

« 31 6 39 70 8 79 6 2 72 8 2 30 58 6 70 38 9 39 2 8 2 »

devient :

« 31639 70879 62728 23058 67038 93928 2 »

On additionne avec le modulo 10 :

« 31639 70879 62728 23058 67038 93928 2 »

+

« 43178 92093 08828 79917 44997 18162 87571 57172 »

=

747 (7+3 ≡ 10 mod(10) ≡ 0) …

=

74707 62862 60546 92965 01925 01080 0

Le message chiffré est donc :

« 74707 62862 60546 92965 01925 01080 0 »

Déchiffrement

On soustrait la clé au message avec le modulo 10 :

« 74707 62862 60546 92965 01925 01080 0 »

-

« 43178 92093 08828 79917 44997 18162 87571 57172 »

=

« 31639 70879 62728 23058 67038 93928 2 »

Et ensuite, on transforme les nombres dans leur lettre respective. Et là, vous vous dites « Mais comment ils peuvent faire la différence entre la lettre de valeur 2 et la lettre de valeur 23 ? Comment ils peuvent savoir si c’est un nombre à 2 chiffres ou à 1 ? ».

Très simple, le chiffre utilisé pour les nombres à 1 chiffre n’est pas utilisé pour démarrer un nombre à 2 chiffres.

En fait, si on tombe sur 3, 7 ou 5, on sait que c’est un nombre à 2 chiffres et donc qu’il faut regrouper le chiffre suivant avec lui.

Dans notre cas, on commence avec un 3, donc on sait qu’on a un nombre à 2 chiffres, on colle le 1 au 3.

« 31 639 70879 62728 23058 67038 93928 2 »

Ensuite, le 6 n’est pas dans (3,7,5), donc c’est un nombre à un seul chiffre :

« 31 6 39 70879 62728 23058 67038 93928 2 »

Et ainsi de suite :

« 31 6 39 70 8 79 6 2 72 8 2 30 58 6 70 38 9 39 2 8 2 »

On remplace enfin les nombres par leurs lettres :

« J A I M E P A S L E S F R A M B O I S E S »

Voilà !

La perfection du chiffrement

Claude Shannon (encore du « name dropping » mais celui-là c’est le vaisseau amiral des cryptographes) prouve mathématiquement que le masque jetable est considéré cryptographiquement sûr, ou inconditionnellement sûr, durant la Seconde guerre mondiale. C’est à dire que le système ne peut pas être percé même si l’adversaire a des moyens illimités ou un temps illimité, tant qu’il ne connaît pas la clé secrète.

Claude Shannon prouve que le masque jetable est « à secret parfait », c’est à dire que si on a un texte chiffré par le masque jetable sous les yeux, il n’y a absolument aucun moyen de deviner quoi que ce soit sur le texte d’origine.

Cela veut dire qu’il est aussi résistant à une attaque par force brute. Si vous essayez toutes les clés de l’univers vous tomberez sur tout les messages de l’univers donc vous n’aurez aucun moyen de savoir lequel est le bon.

Je ne vais pas vous refaire les démonstrations mathématiques ici. Cet article a un but de large diffusion facilement accessible.

Mais pour réaliser cette perfection, il y a quelques problèmes.

Les difficultés

Les difficultés à surmonter pour réaliser un parfait masque jetable sont les suivantes :

La taille et la quantité des clés

Pour chaque échange il faut une nouvelle clé. Pour chaque échange, c’est à dire, chaque personne avec qui vous échangez et chaque texte que vous lui envoyez.

Donc, vous échangez 2 messages avec 2 personnes, ça fait 4 clés. 3 messages avec 3 personnes, 9 clés…

De plus, la clé doit être plus longue que le message.

Car si elle est plus courte et qu’on la répète pour finir le chiffrement, on augmente la probabilité d’apparition de certaines lettres et on peut voir des motifs apparaître donnant des indices sur le message. Ce problème est semblable à la nécessité de l’aléatoire pour créer les clés.

Cela pose des problèmes de stockage des clés de façon sécurisée, le masque s’effondrant si la clé est récupérée par l’adversaire.

L’aspect aléatoire des clés

En français, la lettre « e » est la lettre la plus couramment utilisée, puis c’est « a », puis « s »…

Et des motifs comme « le », « les » sont fréquents. La clé, en se répétant, augmente les probabilités de chiffrer de la même façon des mêmes motifs.

L’attaquant peut repérer ces motifs et parvenir à en déduire le moment où la clé est répétée.

Petit à petit, il peut recomposer la clé ou même faire sans.

Un exemple :

Imaginons la clé « Wesh », l’attaquant ne la connaît pas mais a trouvé que sa longueur était de 4 en analysant les fréquences de motifs récurrents.

Il peut découper ce texte chiffré en groupes de 4 lettres : « Uedl lsll ysfk wqfl myaz kvlp newu zsmj a » et soustraire les groupes entre eux :

Uedl - lsll = X ? + « Wesh » - (Y ? + « Wesh ») = X ? - Y ? + « Wesh » - « Wesh »

= X ? - Y ?

La clé a disparu et on a deux textes qui ne sont plus aléatoires soustraits l’un à l’autre. On analyse la fréquence d’apparition des lettres et on forme des hypothèses. Les lettres, issues de la soustraction, les plus fréquentes ont des probabilités plus élevées d’avoir un « e » dans l’une de leurs lettres de base, etc.

Étape par étape, en multipliant les hypothèses, on réduit les possibilités et on peut parvenir à trouver la clé ou déchiffrer des messages sans elle.

En conclusion, si vous faites une analyse des fréquences en faisant tourner votre ordinateur pendant trois jours, vous obtiendrez le message suivant :

« Y’a le pote condamné qui sortira en douce », toujours Bigflo&Oli, extrait de « Comme d’hab »

Cela vous semble obscur, incompréhensible. Pas de panique, un prochain article éclaircira tout ça avec des exemples.

Donc, pour faire en sorte que chaque lettre ait la même probabilité d’apparaître il faut des clés générées aléatoirement. Mais ça, c’est très compliqué à faire. On sait faire du pseudo-aléatoire mais comme son nom l’indique ce n’est pas complètement aléatoire, les probabilités d’apparition des lettres ne sont pas exactement les mêmes.

La transmission des clés

La transmission des clés n’est pas un problème pour de toutes petites clés (un article expliquera bientôt comment).

Mais cela devient très compliqué dés lors que les clés doivent dépasser une certaine taille (la taille minimale est à l’heure actuelle de 4096 bits voire dans certains cas de fou fou 8192 bits, c’est à dire 1024 octets, 1ko pour les informaticiens).

Donc, souvent, les clés sont échangées physiquement à l’avance. Ce n’est pas pratique et devient très compliqué pour envoyer beaucoup de messages à beaucoup d’interlocuteurs.

L’unicité d’usage

On en revient au même problème que pour la taille des clés et l’aspect aléatoire des clés.

Si on réutilise une clé, on perd l’aspect aléatoire et le message chiffré est de nouveau sensible à une analyse des fréquences.

Le problème est plus grave encore car l’unicité d’usage suppose la destruction de la clé après utilisation et il n’existe pas de moyen facile pour s’assurer que vos interlocuteurs ne gardent pas les clés dans un coin au risque de se les faire voler plus tard (dans 5 ans, 10 ans…) ou ne les réutilisent pas pour d’autres messages de leur côté.

L’empoisonnement du message

Le dernier soucis possible est l’empoisonnement des clés mais cela peut être réglé assez facilement (du moins temporairement) en informatique.

Comme le masque jetable est insensible à la force brute (toutes les clés de l’univers donnant tous les messages de l’univers), un attaquant peut s’amuser à modifier le message chiffré pour lui donner un sens différent.

Il peut aussi modifier la clé sans forcément la connaître et ainsi modifier le message en clair.

Exemple :

Reprenons notre fameux message :

« J’aime pas les framboises »

que l’on chiffre avec la clé :

« nzhtjplgpggsefirksxohsbyhkazsb »

en modulo 26 (donc sans l’apostrophe), on obtient :

« N zrry rrg yef eytvqzohky »

L’attaquant ne connaît que ce message secret mais il peut modifier la clé de chiffrement. Il remplace donc la clé par :

« ezjfuqjcltbmtcvihgdtgefirksxohsbyhkazsb »

Et ça donne le message clair suivant :

« Jaimebienlesfraisiers »

Donc, pas du tout le message original.

Pour éviter ça, en informatique, on peut signer et faire un hachage du message et des clés et donc un utilisateur peut vérifier que le message qu’il reçoit est bien conçu par la bonne clé et que la clé qu’il utilise est toujours la bonne.

Nous reviendrons sur le fonctionnement d’une signature et d’un hachage dans de prochains articles.

Je crois qu’on a déjà largement dépassé les 2000 mots. On va s’arrêter là.

Un peu d’histoire

Contrairement à ce que suggère son appellation le chiffre de Vigenère semble avoir été conçu par Giovan Battista Bellaso, un cryptographe italien du 16ème siècle.

Malgré tout, c’est le chiffre de Vigenère qui restera et non celui de Bellaso.

Blaise de Vigenère présente son chiffrement 20 ans après Bellaso avec des évolutions par rapport à celui-ci.

On nomme cette méthode de chiffrement Vigenère à partir du 19ème siècle sans se soucier de Bellaso. De plus Bellaso a été rapidement oublié au profit de Porta.

Plein de noms. Ah, l’histoire !

Bien sûr, ce chiffre n’est pas sûr et a été cassé dès le 19ème siècle.

La clé à la place du décalage

Le chiffre de Vigenère introduit une grande innovation par rapport au chiffre de César : la notion de clé.

Cette différence place ce chiffrement comme polyalphabétique et non plus monoalphabétique. On n’a plus « une lettre en clair donne une, et seulement une, lettre chiffrée » mais on peut avoir une lettre en clair qui donne deux lettres chiffrées différentes et une lettre chiffrée qui peut venir de deux lettres en clair différentes.

On utilise donc plusieurs alphabets de substitution (différents décalages de lettres dans un même message) contrairement au chiffre de César. D’où le mot « polyalphabétique ».

Les règles de substitution (comment on passe d’un alphabet à l’autre) sont données par les lettres de la clé et une table de substitution.

Vous n’avez pas tout compris ? On va illustrer ça par des exemples dans les chapitres suivants, ne vous inquiétez pas.

De plus, un autre article reviendra sur la classification des chiffrements.

Le chiffre lui-même

On entre donc dans le vif du sujet. Il y a deux façons de se représenter le chiffre de Vigenère le plus classique (avec les variantes, c’est une autre histoire).

Représentation par table

Pour la représentation par table, on a besoin d’une table (oui, oui), ou plutôt d’un tableau de substitution. Le voici :

Ça vous semble touffu mais ça ne l’est pas tant que ça. Si vous regardez les lignes de la table, vous voyez l’alphabet latin avec un décalage d’une lettre par ligne. De même, si vous regardez les colonnes.

Le chiffre consiste à prendre la lettre à l’intersection de la lettre du message en clair (les colonnes) et la lettre de la clé (les lignes). Cette lettre à l’intersection est celle du message chiffré.

Exemple :

Chiffrement

Prenons le message : « J’ai plaqué mon chêne » (extrait de « Auprès de mon arbre » de Georges Brassens)

Et la clé : « Una mattina » (extrait de « Bella Ciao »)

On regarde l’intersection de chaque lettre :

La colonne « J » et la ligne « U » donnent « D »,

la colonne « a » (on oublie l’apostrophe pour l’instant) et la ligne « n » donnent « n »,

la colonne « i » et la ligne « a » donnent « i »,

etc.

Si le message dépasse la clé en longueur, on répète la clé. On considère le « ê » et le « é » comme un « e ».

On obtient donc :

« D ni bltjcr mia ctegx »

Déchiffrement

Pour le déchiffrement, on regarde pour chaque ligne, correspondant à la lettre de la clé, où se situe la lettre du message chiffré et on prend la lettre en haut de la colonne correspondante qui est celle du message en clair.

Donc, en reprenant la clé : « Una mattina »

Et le message chiffré : « D ni bltjcr mia ctegx »

Dans la ligne « U », la lettre « D » est à la dixième position, donc la colonne « J »,

dans la ligne « n », la lettre « n » correspond à la première position, la colonne « a »,

etc.

On retrouve donc :

« J ai plaque mon chene »

Représentation par congruence

La deuxième représentation est la représentation mathématique, la congruence. Si ce mot ne vous dit rien, regardez cet article.

Pour utiliser la congruence, on va substituer les lettres par des chiffres. On utilise la règle suivante :

A=0, B=1, C=2, D=3, E=4, F=5, G=6, H=7, I=8, J=9, K=10, L=11, M=12, N=13, O=14, P=15, Q=16, R=17, S=18, T=19, U=20, V=21, W=22, X=23, Y=24, Z=25

Et pour chiffrer, on additionne la clé au message. Pour déchiffrer, on soustrait la clé du message.

Exemple :

Chiffrement

On reprend notre message : « J’ai plaqué mon chêne »

Et notre clé : « Una mattina »

On va aligner le message et la clé (en enlevant l’apostrophe et les accents) et répéter la clé pour couvrir tout le message :

« J ai plaque mon chene »

+

« Una mattina Una matti »

=

9

+

20

=

29

On n’a pas de lettre de valeur 29 (le maximum c’est 25), donc on utilise la congruence. On considère un modulo 26 (de 0 à 25, 26 nombres).

Donc,

$$ 29 \equiv 29-26 \pmod{26} \equiv 3 \pmod{26} = D $$

On peut continuer nos calculs :

« J ai plaque mon chene »

+

« Una mattina Una matti »

=

9

+

20

=

29

≡

3 mod(26)

=

D

Et ainsi de suite. On retrouve le message chiffré : « D ni bltjcr mia ctegx »

Déchiffrement

Pour déchiffrer, on soustrait la clé au message chiffré. On utilise toujours la congruence, bien sûr.

« D ni bltjcr mia ctegx »

-

« Una mattina Una matti »

=

3

-

20

=

-17

≡

-17+26 mod(26)

≡

9 mod(26)

=

J

Et, de niveau, étape par étape, on retombe sur :

« J ai plaque mon chene »

Variantes

Le chiffre de Vigenère a connu de multiples variations. En voici quelques unes :

Le précurseur Bellaso

Avant Vigenère, il y avait eu Bellaso. Mais le pauvre homme s’est fait piqué la vedette par un autre italien, plus connu à son époque, Giovanni Della Porta, puis par Vigenère. Bref, du coup on parle du chiffre de Porta/Bellaso.

Pour ce chiffre, il faut une table que voici :

Dans la colonne de gauche se trouve la lettre de la clé, et dans la colonne de droite se trouve la substitution.

Un petit exemple pour vous montrer comment ça fonctionne :

Chiffrement

Prenons le message suivant : « Trois Anneaux pour les Rois Elfes » (extrait du « Seigneur des anneaux » de Tolkien)

Avec la clé suivante : « La République Galactique » (extrait de « Starwars » de Lucas)

La première lettre de la clé est « L ».

On cherche dans la première colonne et cette lettre (« L »)est dans la sixième ligne avec « K ».

La première lettre du message est « T ». On cherche donc la lettre « T » dans la deuxième colonne à la sixième ligne.

On voit que « T » se trouve en dessous de « L » (dans les deux lignes présentes dans chaque ligne de la deuxième colonne), donc la lettre chiffrée est « L ».

On passe à la deuxième lettre de la clé (pour être sûr que vous suivez). C’est la lettre « a ».

Elle se situe à la première ligne dans la première colonne. La deuxième lettre du message en clair est « r ».

Dans la deuxième colonne de la première ligne, « r » est en dessous de « e », donc la lettre chiffrée est « e ».

Ensuite :

« R » : 9ème ligne : « o » devient « j »,

« e » : 3ème ligne : « i » devient « t » (« i » est au dessus de « t »),

etc.

Le message chiffré est donc :

« Lejtm qafnsem fbme xvb ijyh zyxpm »

Déchiffrement

Vous reprenez la clé, vous retrouvez la ligne et faites la correspondance. Donc :

Avec la clé : « La République Galactique »

Et le message chiffré : « Lejtm qafnsem fbme xvb ijyh zyxpm »

« L » : 6ème ligne : « L » devient « T »,

« a » : première ligne : « e » devient « r »,

etc.

On retombe sur le message : « Trois Anneaux pour les Rois Elfes »

Beaufort

On passe rapidement sur cette variante et la suivante. La seule différence avec Vigenère est qu’au lieu d’additionner la clé au message pour chiffrer, on soustrait le message à la clé.

Donc pour déchiffrer, on soustrait le message chiffré à la clé :

Clé – Message = Chiffré => Message = Clé – Chiffré

Bien sûr, c’est selon la représentation par congruence.

Variante allemande de Beaufort

Pour cette variante, c’est le contraire. On soustrait la clé au message pour chiffrer.

Et pour déchiffrer, on additionne le message chiffré à la clé :

Message – Clé = Chiffré => Message = Clé + Chiffré

Alphabet désordonné

On peut s’amuser à mettre les lettres de l’alphabet dans le désordre. Si les deux correspondants ont bien la même table, le système fonctionne.

Bien sûr, il faut qu’il n’y ait qu’une seule fois chaque lettre par colonne et par ligne.

Il faut aussi que toutes les lettres soient présentes dans toutes les colonnes et toutes les lignes.

Par exemple, on peut considérer ces valeurs :

C=0, E=1, A=2, Z=3, B=4, D=5, F=6, G=7, H=8, I=9, J=10, K=11, L=12, M=13, N=14, O=15, P=16, Q=17, R=18, S=19, U=20, T=21, V=22, W=23, X=24, Y=25

Alphabet agrandi ou différent

On a travaillé sur un alphabet latin de 26 lettres mais rien n’interdit de l’agrandir pour inclure des signes supplémentaires voire d’utiliser un autre alphabet.

Par exemple :

A=0, B=1, C=2, D=3, E=4, F=5, G=6, H=7, I=8, J=9, K=10, L=11, M=12, N=13, O=14, P=15, Q=16, R=17, S=18, T=19, U=20, V=21, W=22, X=23, Y=24, Z=25,!=26,?=27

Dans ce cas, on a un modulo 28 et non 26.

Variantes de Bellaso

On a utilisé la table originale de Bellaso mais rien n’interdit de la transformer.

On peut très bien avoir trois lettres dans la première colonne au lieu de deux et réduire le nombre de lignes en conséquence.

Ou avoir un nombre de lettres différentes par ligne.

Ou changer les substitutions d’alphabet dans la deuxième colonne.

La seule chose que cette table impose est que le nombre de lettres/signes de votre alphabet soit pair pour que chaque signe ait une correspondance dans la deuxième colonne.

Faiblesses

Attaque par analyse de fréquences

Comme rappelé au préambule historique, ce chiffre, ainsi que ses variantes, a été cassé au 19ème siècle.

Il souffre de la même faiblesse, même s’il est beaucoup plus résistant, que le chiffre de César.

Les langues n’utilisent pas les mêmes lettres avec les mêmes fréquences. Par exemple, en français, la lettre « e » est beaucoup plus utilisée que les autres.

Un attaquant peut se servir de cette différence de fréquences pour deviner le message ou la clé.

Mais contrairement au chiffre de César, il y a une étape préalable.

L’attaquant doit, d’abord, chercher à deviner la longueur de la clé. Cela lui permet de définir des segments de longueur égale dans le message chiffré.

Pour ça, il recherche des motifs dans le message chiffré. C’est à dire des groupes de trois lettres ou plus qui sont présents de manière régulière dans le message chiffré.

En effet, les langues ont aussi des motifs qui reviennent souvent : « les » apparaît souvent en français, par exemple.

La probabilité est plus forte que le même bout de la clé tombe sur un même motif du message en clair et donc chiffre de la même façon, qu’un simple phénomène aléatoire.

En repérant ces motifs, l’attaquant estime donc la taille de la clé et peut segmenter le message chiffré.

Chaque lettre du message en clair, dans le segment, étant chiffré par la même lettre de la clé, on peut revenir à l’étude de fréquences des lettres.

Cela vous semble obscur, incompréhensible. Pas de panique, un prochain article éclaircira tout ça avec des exemples.

Le chiffre de Vigenère est à mi-chemin entre le chiffre de César, dont il tire la règle de substitution, et le masque jetable, qui est l’algorithme parfait, qui n’apparaîtra qu’au début du 20ème siècle.

Énigme de Cryptotrucs

Le Carré de Polybe est 6x6.

La clé est : « les framboises savent »

Le message chiffré est : « 12 11 11 12 33 12 42 16 42 24 11 11 23 31 16 44 26 12 32 15 23 43 44 12 31 31 12 »

La congruence a été, pour la première fois, formellement étudiée à la fin du 18ème siècle et au tout début du 19ème siècle par Carl Friedrich Gauss, le « master » des mathématiciens.

Il a laissé son nom à la courbe en cloche dite « courbe de Gauss ».

Auparavant, on utilisait la congruence sans avoir conscience de ses propriétés, tout comme on sait additionner 2 carottes et 3 carottes sans avoir conscience que c’est un calcul de somme en arithmétique.

C’est bien mignon tout ça, mais sinon, qu’est-ce que c’est ?

Le principe

La congruence est une structure mathématique, c’est à dire un ensemble de règles, qui permet de relier des nombres entiers entre eux dans un ensemble fini.

C’est à dire que si on considère une congruence de module (ou modulo) n (on verra plus loin ce qu’est un module), on a les propriétés suivantes :

• $$ a \equiv a \pmod{n}, $$
• $$ \text{si } a \equiv b \pmod{n} \quad \text{alors } b \equiv a \pmod{n}, $$
• $$ \text{si } a \equiv b \pmod{n} \quad \text{et } b \equiv c \pmod{n} \quad \text{alors } a \equiv c \pmod{n}, $$
• $$ \text{si } a \equiv b \pmod{n} \quad \text{et } c \equiv d \pmod{n} \quad \text{alors } a+c \equiv b+d \pmod{n} \quad \text{et } a \times c \equiv b \times c \pmod{n} $$

Et la vous vous dites « J’ai rien compris. Pourquoi il y a trois barres dans son égal ? Ça veut dire quoi ce mod ? Tant de questions ? »

Ne vous inquiétez pas. On va faire des exemples et des représentations plus claires.

On boucle, on boucle

Une autre façon de se représenter la congruence et le modulo, c’est sous la forme d’une boucle ou d’un cycle.

Un petit exemple, les minutes

Imaginez que vous regardez une horloge et vous ne vous occupez que de l’aiguille des minutes.

Vous voulez additionner 45 minutes et 30 minutes mais vous ne vous préoccupez pas de l’heure (juste l’aiguille des minutes). Vous trouvez quoi ?

15 minutes, non ?

Félicitations, vous avez fait un calcul de congruence de module 60 (ou modulo 60).

Et vous pouvez ajouter des nombres bien plus grands que 60 (ou n’importe quel autre module). Il faut soustraire 60 du résultat autant qu’on peut. Le résultat doit être compris dans l’ensemble (donc ici entre 0 et 59).

Combien font 59 + 258 minutes modulo 60 ?

Réponse à la fin de ce billet de blog.

Un deuxième petit exemple, les heures

Maintenant, avec les heures. Vous ne regardez que l’aiguille des heures (vous oubliez les minutes). Vous ajoutez 5 heures à 8 heures. Vous trouvez quoi ? Attention, c’est une horloge.

1 heure, non ? (vu qu’une horloge n’affiche que 12 heures)

Vous avez fait un calcul de congruence de module 12.

Et du coup, pourquoi un signe égal avec trois traits ? Et bien, parce que ce résultat dans le deuxième exemple n’est pas égal à 1, vu qu’on a enlevé des heures en trop. Donc on le note avec ce signe qu’on appelle « congru ».

Vous voyez qu’on peut faire des additions avec des nombres immenses tout en gardant un résultat dans des nombres limités (un ensemble fini). La taille de la congruence limite la possibilité des résultats. Ici, par exemple, l’ensemble contient 12 nombres, les 12 heures d’une horloge.

Bien sûr, comme c’est un cycle, ça marche aussi en soustrayant des heures et avec des nombres entiers négatifs. Il faut bien sûr, additionner ensuite le module pour revenir dans l’ensemble de nombres (donc ici entre 0 et 11).

Combien font donc : 2-18 heures modulo 12 ?

Réponse à la fin de ce billet de blog.

Encore un exemple, les doigts

Si vous considérez les doigts d’une main, vous avez une congruence de 5 (généralement) et les doigts de 2 mains, vous avez une congruence de 10.

Pas convaincus ?

Prenez juste une main et comptez avec vos doigts 3+4, combien avez-vous de doigts qui restent ?

2, je pense.

Maintenant, prenez 2 mains et comptez 8+9, combien avez-vous de doigts qui restent ?

7, non ?

J’utilise le terme « reste » exprès. Vous allez voir.

Et le reste ?

On peut voir aussi la congruence comme le reste d’une division (euclidienne, pour les connaisseurs).

Le dénominateur d’une division (le nombre en dessous) est le module et quand vous avez fini votre division, ce qui reste est le « reste », justement.

Attention, il est important de se rappeler que cela fonctionne avec des entiers donc pas de virgule, vous arrêtez votre division avant que le reste n’ait une virgule.

Donc, si on divise 3 par 2, on a quel reste ?

1 bien sûr.

Et si on divise 5 par 2, quel reste ?

1 aussi, pas mal.

Du coup, ça veut dire que 1 ≡ 3 mod(2) et 1 ≡ 5 mod(2), on est d’accord ?

Et donc :

$$ 1 \equiv 3 \pmod{2} \equiv 5 \pmod{2} $$

Maintenant, est-ce que le reste de 33/26 et le reste de 85/26 sont congrus ?

Réponses

Combien font 59 + 258 minutes modulo 60 ?

$$ 59+258 = 317 \equiv 317-60 \times 5 \pmod{60} $$

(on a 5 fois 60 qui est plus petit que 317)

$$ \equiv 317-300 \pmod{60} \equiv 17 \pmod{60} $$

Donc :

$$ 59+258 \equiv 17 \pmod{60} $$

Combien font : 2-18 heures modulo 12 ?

$$ 2-18 = -16 \equiv -16+12 \pmod{12} \equiv -4 \pmod{12} $$

(c’est encore négatif, donc pas entre 0 et 11)

$$ \equiv -4+12 \pmod{12} \equiv 8 \pmod{12} $$

Donc : $$ 2-18 \equiv 8 \pmod{12} $$

Est-ce que le reste de 33/26 et le reste de 85/26 sont congrus ?

$$ 33/26 = (26+7)/26 $$

donc le reste est 7.

$$ 85/26 = (26+59)/26 $$

59 est plus grand que 26, on continue

$$ = (26+26+33)/26 $$

tiens donc 33, comme pour la première division, on continue

$$ = (26+26+26+7)/26 $$

donc le reste est 7.

Donc, oui, le reste de 33/26 et le reste de 85/26 sont congrus.

Le chiffre de César, comme son nom ne l’indique pas, était déjà, semble-t-il, utilisé par les Spartiates, donc bien avant Jules César.

C’est une variation du chiffrement par décalage qui est un chiffrement par substitution. Des mots compliqués pour des concepts simples, vous verrez.

Auguste utilisait une autre variante du chiffre de César.

Il est très possible qu’il ait inspiré le chiffre de Vigenère.

La grosse image : la substitution

On va commencer par la notion la plus large. Le chiffrement par substitution consiste à remplacer une lettre par une autre. Tout simplement.

Cette technique est la plus répandue dans l’histoire et elle est différente de la permutation qui consiste à changer l’ordre des lettres dans un texte.

Les algorithmes modernes utilisent les deux méthodes à la fois car, seule, la substitution n’est pas cryptographiquement très sûre (sauf le cas très particulier du masque jetable).

La moyenne image : le décalage

Dans les méthodes de chiffrement par substitution, la plus simple est la méthode par décalage.

C’est une méthode de chiffrement monoalphabétique (encore un mot compliqué pour une notion simple). C’est à dire qu’une lettre est associée (lors du chiffrement/déchiffrement) à une autre et uniquement à cette autre. Deux lettres différentes ne peuvent pas aboutir à une même lettre après chiffrement/déchiffrement et, de même, une lettre ne peut pas donner deux lettres différentes après chiffrement/déchiffrement.

Pour les mathématiciens, c’est une relation bijective.

La méthode par décalage consiste donc à décaler une lettre dans l’alphabet.

La petite image : le chiffre de César

Le chiffre de César désigne, à l’heure actuelle, toutes ces méthodes de chiffrement par décalage mais, plus précisément, le décalage par 3.

Prenons l’alphabet latin, celui utilisé par César (même s’il semble qu’il préférait l’alphabet grec pour ses messages secrets) et affectons des valeurs aux lettres.

A=0, B=1, C=2, D=3, E=4, F=5, G=6, H=7, I=8, J=9, K=10, L=11, M=12, N=13, O=14, P=15, Q=16, R=17, S=18, T=19, U=20, V=21, W=22, X=23, Y=24, Z=25

On leur applique un décalage de 3.

A=0+3=3=D

B=1+3=4=E

…

Par contre, vous voyez que si on fait :

X=23+3=26

et on ne sait pas ce que c’est la lettre 26, sauf si on utilise la congruence. Si ce mot vous est inconnu, lisez cet article.

On va considérer que l’alphabet latin est en modulo 26. Donc, si on reprend le calcul :

X=23+3=26 ≡ 26-26 *mod*(26) ≡ 0 *mod*(26) ≡ A

Donc, dans le chiffre de César, A devient D, B devient E, X devient A, Y devient B, Z devient C…

On a décalé les lettres de 3 crans.

Un exemple :

Considérons le message : « CAVE CANEM » (« Attention au chien », en latin)

On applique le chiffre de César :

« C A V E C A N E M »

=

2 0 21 4 2 0 13 4 12

+3

=

5 3 24 7 5 3 16 7 15

=

« F D Y H F D Q H P »

Voilà votre message chiffré. Et pour le déchiffrer on fait le contraire, on soustrait 3 aux lettres du message chiffré.

C’est simple, n’est ce pas. Et vous comprenez qu’on en est au degré 0 de la cryptographie.

Mais pour l’époque, ça paraissait suffisant.

Les variantes

Bien sûr, on a développé des variantes de ce chiffrement durant l’histoire.

ROT13

Cette variante consiste à faire un décalage de 13 lettres et non de 3. « ROT » est le raccourci de rotation, car un décalage avec un modulo peut être analysé comme une rotation.

Ce décalage est particulier car il est symétrique pour un alphabet de 26 lettres (13 étant la moitié de 26). C’est à dire que si on chiffre deux fois un message avec ce décalage on retrouve le message en clair.

Exemple :

Premier chiffrement :

« C A V E C A N E M »

=

2 0 21 4 2 0 13 4 12

+13

=

15 13 34-26 17 15 13 26-26 17 25

=

15 13 8 17 15 13 0 17 25

=

« P N I R P N A R Z »

Deuxième chiffrement :

« P N I R P N A R Z »

=

15 13 8 17 15 13 0 17 25

+13

=

28-26 26-26 21 30-26 28-26 26-26 13 30-26 38-26

=

2 0 21 4 2 0 13 4 12

=

« C A V E C A N E M »

Tadaa, on retrouve « Cave Canem ».

Auguste

J’ai dit plus haut que le chiffre de César était nul. Attendez de voir celui-là. Oubliez les modulo, c’est trop compliqué, et compter jusqu’à 3 c’est aussi trop compliqué, comptez jusqu’à 1, c’est très bien.

Auguste (le neveu de César, donc) utilisait un chiffrement par décalage de 1. Oui, vous avez bien lu, de 1. Ah et puis « z » on en fait quoi ? Rappelez-vous, pas de congruence. Donc « z » devient « aa », oui, deux « a ».

Dois-je vraiment vous faire un exemple ?

Avocat, Cassis, Cassette, K9

Il y a, bien sûr, des chiffrements provenant de jeux de mots, inventés pour les jeux pour enfants.

Avocat est « A vaut K » donc un décalage de 10.

Cassis est « K 6 », un décalage de 4 en arrière (ou 22 en avant).

Cassette est « K 7 », un décalage de 3 en arrière (23 en avant).

K9 est prononcé en anglais et est une référence au chien robot de Dr Who (et c’est aussi une très bonne app mail pour Android…). C’est un jeu de mots avec le mot « canine » bien sûr. C’est un décalage de 1 en arrière (25 en avant).

Extension de l’alphabet

On peut, bien sûr, utiliser un autre alphabet que l’alphabet latin, voire prendre un ordre arbitraire de signes. Tout ce qu’il faut c’est que les signes soient ordonnés.

Exemple :

Prenons cet alphabet fictif :

« : ; ! , t 2 5 »

Si on applique un incrément de 3, on a :

« , t 2 5 : ; ! »

La nullité du truc

Vous avez compris, maintenant, comme ce système était nul. Voyons deux méthodes pour casser un chiffrement fait avec cette technique.

Cassage par fréquences

Chaque langue a des lettres plus fréquentes que les autres. Par exemple, en français « e » est (de loin) la lettre la plus fréquente. Il suffit donc à un attaquant d’analyser la fréquence des signes dans le message. Si le message chiffré contient beaucoup de « g » et que les interlocuteurs sont français alors l’attaquant peut faire l’hypothèse d’un décalage de 2 et retrouver facilement le texte original.

Cassage par force brute

Pour un alphabet de 26 lettres, il y a 26 combinaisons possibles. Ce n’est franchement pas compliqué de tester toutes les combinaisons.

Tester toutes les combinaisons, cela s’appelle une attaque par force brute. C’est le plus bête (le plus brut), on teste toutes les combinaisons. Mais c’est aussi l’attaque qui demande le plus de ressources, vu qu’on teste tout.

Premier mois

octobre 2, 2018 09:00:00

Bon, on retourne au boulot.

octobre 2, 2018 17:00:00

Je vais commencer à développer ce service. Ça nous sera utile !

octobre 6, 2018 10:00:00

Ok, alors l’idée c’est de faire un service qui permette de communiquer avec Lee.

octobre 6, 2018 17:00:00

Il faudrait qu’il soit totalement flexible en fait. Je sais pas ce que Lee veut en faire.

octobre 7, 2018 11:00:00

Je vais me servir du réseau entre réseau Internet.

octobre 7, 2018 14:00:00

En me servant des connexions existantes, chiffrer les paquets 📦…

Ouais, ça peut marcher.

octobre 8, 2018 13:00:00

Hum… Essayer de refaire un réseau local détaché de l’entre réseau Internet.

octobre 8, 2018 14:00:00

Tout en se servant de ce réseau.

octobre 8, 2018 18:05:00

Tiens, Lee a précisé des choses sur les phrases de passe.

octobre 9, 2018 11:00:00

J’ai entendu dire qu’au site de la Grande Pomme ils jetaient des masques partout.

Lee va devoir expliquer plus de trucs.

octobre 9, 2018 13:00:00

J’ai encore une belle pile de clés pour le masque jetable.

octobre 9, 2018 15:00:00

Qu’est-ce qui se passe ? Le site de la Vallée de la Silice est attaqué.

octobre 9, 2018 17:00:00

Faut que je prévienne Gazouilleur Twitter qu’il donne l’alerte.

octobre 9, 2018 18:00:00

Bon Gazouilleur m’a engueulé en me disant qu’il le savait déjà.

• Moi : Bon ben on fait quoi du coup ?
• Lui : Euuuhhh… Je sais pas.
• Moi : J’admire la force de tes propositions. Ça fait plaisir. On recule vers l’intérieur du site.

octobre 10, 2018 16:00:00

On est bombardé de paquets 📦. Tout les ports ⚓ sont bouchés.

Même le 443ème, le plus sécurisé.

Les communications fléch…

octobre 13, 2018 17:00:00

On s’est replié avec le peuple oiseau 🐦 On est derrière des 🍯

octobre 13, 2018 18:00:00

De temps en temps Oiseau tonnerre vient avec du courrier du front.

Les gardes suricates Suricata_IDS essayent de prévenir les intrusions.

octobre 14, 2018 15:00:00

Les 🍯 ont collé les paquets 📦. L’attaque a cessé.

Je vais pouvoir continuer mon développement.

octobre 14, 2018 16:00:00

Avec ces attaques régulières, un moyen de garder les communications malgré tout, c’est pas du luxe.

octobre 14, 2018 17:00:00

Lee m’a parlé via un masque jetable de son projet de base de recherche ⚗️..

J’ai entendu dire qu’il était parti en vacances. Hum… Je crois pas non.

octobre 15, 2018 14:00:00

De retour dans mon nid. Gazouilleur Twitter est retourné à son poste de crieur public.

Oiseau tonnerre redistribue le courrier en retard.

Lee m’a envoyé du courrier.

Il est de retour sur le site de la Grande Pomme.

octobre 15, 2018 16:00:00

Il faudra quand même finir par savoir quelquechose sur ces aggresseurs.

Ça ne semble pas être eux.

octobre 15, 2018 19:00:00

Des nouvelles du site de la Grande Pomme.

Il semble qu’ils aient cessé de jeter des masques partout. Je me demande si Lee est derrière ça.

octobre 16, 2018 11:00:00

Bon retour au boulot. J’en étais oû ? faut que ça avance.

Lee m’envoie un tas de messages avec le masque jetable. La pile de clés s’amenuise.

octobre 16, 2018 13:00:00

Le routage 🖧 c’est bon. Le chiffrement maintenant.

octobre 17, 2018 15:00:00

Ok, ces protocoles sont considérés cryptographiquement sûr, on y va.

octobre 17, 2018 17:00:00

TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 Je crois que j’ai ce qu’il faut là.

Je pense que Lee expliquera ce qui semble être un charabia un jour.

octobre 20, 2018 11:00:00

Côté serveur c’est bon.

octobre 20, 2018 17:00:00

Le client. Qu’est ce que je fais avec le client ?

octobre 21, 2018 15:00:00

Il faut que ce soit compatible avec les clients OpenVPN pour ne pas piéger les utilisateurs dans cette solution.

octobre 21, 2018 17:00:00

Du coup, je vais faire en sorte qu’on utilise ces clients Openvpn.

J’aurais beaucoup prononcé OpenVPN aujourd’hui… OpenVPN, OpenVPN, OpenVPN…

octobre 22, 2018 11:00:00

Je vais nommer un client fonctionnant sur ce réseau

• ⬇️<
• un accès
• Je me suis vraiment cassé le crâne pour le nommer 🤔

octobre 22, 2018 13:00:00

Il faut que je travaille la double authentification de ces accès.

octobre 22, 2018 18:05:00

Tiens, Lee fait un truc sur ça justement.

octobre 23, 2018 14:00:00

Bon, continuons pour l’authentification. alors quelque chose qu’on a…

Une clé correspondant à un certificat. Pour que ce soit compréhensible, vite l’analogie du cadenas.

octobre 23, 2018 15:00:00

Et l’analogie s’arrête là. Puisque un certificat ça peut se révoquer. Faudra vraiment que Lee explique tout ça.

octobre 24, 2018 15:00:00

J’ai entendu parler d’un artéfact prés du noyau. Il faut que j’y aille discrètement.

octobre 27, 2018 14:00:00

J’ai trouvé l’artéfact. Je rentre à tire-d’aile l’étudier.

octobre 28, 2018 13:00:00

J’ai étudié l’artéfact. woooo 😮. Je vais l’envoyer à Lee.

octobre 28, 2018 15:00:00

Il faut que je termine mon service parceque avec ce que j’ai trouvé on va en avoir rapidement besoin.

Je suis pas loin de l’avoir fini. Y a plein de fonctionnalités qu’il faudra expliquer.

Deuxième mois

octobre 29, 2018 10:00:00

Bon, j’ai ce qu’il faut. Le nom du machin maintenant. Ben on fait avec mon nom.

MyCrypNet ça sonne bien je trouve. Ah… et Lee a trouvé un artéfact de son côté. Avec le mien… Zut, je lui ai pas envoyé !!!

octobre 30, 2018 13:00:00

Bon allez. On prépare les bagages pour l’archipel.

Il va falloir que je délègue des portions de mon réseau MyCrypNet aux autres oiseaux pour rester en contact.

octobre 31, 2018 13:00:00

J’ai vu avec Lee la répartition sur l’archipel. Il aura le grand site central, j’aurais un petit site.

novembre 1, 2018 13:00:00

J’ai quand même des doutes. J’ai peur que des membres de mon peuple, les oiseaux, soient des espions de ces fruits rouges.

J’ai percuté que le gardien 🐧 du noyau m’avait vu prendre l’artéfact. Il n’a rien dit. J’ai confiance, je vais lui parler de MyCrypNet.

novembre 2, 2018 13:00:00

Gardien 🐧 : Mike.dire( Mike.déplacer( Mike, lieu: loin)) et Mike.dire( Mike.créer((objet) MyCrypNet)) et Gardien.voir( MyCrypNet.créé( lieu: nanovers)) donc Gardien.dire( Gardien.savoir( Mike.créer((objet) MyCrypNet)))

novembre 3, 2018 13:00:00

Du coup j’ai pas tout compris. Ce gardien parle étrangement.

Bon, je suis de retour dans mon nid. Il va me falloir une équipe pour diffuser MyCrypNet auprès des résistants à la baie écarlate. Je contacte Lee.

novembre 4, 2018 13:00:00

Faut que je définisse le logo. Je vais prendre le blason familial.

Dans ma famille, le nom est en premier. Donc, mon nom c’est Mike.

C’est fait. Le gardien 🐧 vient de me dire : Gardien.voir( MyCrypNet.modifié( logo, lieu: nanovers))

Euuhhhhh…

novembre 5, 2018 10:00:00

Au lieu de bayer aux corneilles, je vais essayer de me renseigner un peu plus sur les fruits rouges présents dans la vallée de la silice.

Ont-ils infiltrés mon peuple ?

novembre 6, 2018 13:00:00

Bon, après investigations, tout le monde est innocent comme la blanche colombe.

C’est chouette. Je suis gai comme un pinson et je siffle comme un merle.

novembre 7, 2018 13:00:00

Lee m’a envoyé Bob. Un chat 🐈 parmi les oiseaux 🐦, ça promet.

Enfin, c’est un chat 🐈 technicien, il n’est pas câblé de façon standard.

Ça a été quand même une volée de moineaux à son arrivée. Mais ça va, les autres reviennent.

novembre 8, 2018 13:00:00

J’ai expliqué à Bob comment installer MyCrypNet.

Il a trouvé ça super simple, il l’a même répété (oui, je sais je m’envoie pas des fleurs).

Il va diffuser l’information auprès de son clan. Brave petit chat 😽…

novembre 9, 2018 13:00:00

Bon mon petit Bob. Les paquets 📦 circulent chiffrés au sein de MyCrypNet.

Un algorithme pour vérifier que les accès MyCrypNet ne sont pas des hackers, un pour échanger des clés entre accès.

Un pour vérifier qu’un hacker n’a pas modifié un paquet 📦 en voyage…

novembre 10, 2018 13:00:00

Bob apprend vite. Il est occupé à tester le truc là.

Bon, du coup j’ai pas avancé sur mon déplacement vers le multisite et comment l’annoncer.

novembre 11, 2018 10:00:00

Je suis allé voir le chef aujourd’hui. Il m’a expliqué que les oiseaux 🐦 ne pouvaient pas être infiltrés par les framboises car ils viennent du noyau.

J’ai rien compris…

novembre 12, 2018 13:00:00

Alors, le chef m’a expliqué. En fait, le peuple oiseau 🐦 était venu du noyau juste avant ma naissance. Je suis donc le seul oiseau à être né dans ce monde…

Ok, c’est pas plus clair. Ce monde ? Par rapport à quoi ? Et c’est quoi ce noyau ?

novembre 13, 2018 13:00:00

Le chef continue de m’expliquer des trucs. Donc, si j’ai bien compris, au sein du noyau se trouvait Pi-framboise, le fondateur, qui n’a pas pu tenir la charge de toute l’organisation des fruits rouges. Il ne sait pas, par contre, comment ils sont arrivés sur Kookati.

novembre 14, 2018 13:00:00

De son côté, Bob m’épate. Il apprend trés vite, même pour un chien 🐕 technicien qu’il n’est pas. Je lui délègue la gestion des appareils, ce sera notre administrateur réseau.

novembre 15, 2018 13:00:00

J’ai expliqué à Bob que Lee est en train de chercher un lapin 🐇. Il est moyennement ravi. Il y a des tensions entre le clan des chats 🐈 et celui des lapins 🐇.

novembre 16, 2018 13:00:00

Bon, avec Bob, on va se détendre un peu autour d’un verre d’alcool isopropylique. On se raconte des blagues.

Logarithme et exponentielle sont au restaurant. Qui paye l’addition ?

…

exponentielle car logarithme népérien (ne paye rien)

Voilà, voilà

novembre 17, 2018 13:00:00

Revenus de notre gueule de bois, Oiseautonnerre et Pigeon nous donnent des mauvais échos venant de la Grande Pomme.

Bob est inquiet pour les siens. Moi pour Lee.

En plus, la vallée de la Silice semble aussi visée par les framboises.

novembre 18, 2018 13:00:00

J’ai eu des échos d’une invasion d’envergure de la part des framboises planifiée pour dans plusieurs mois.

Les suricates Suricata_IDS détectent de plus en plus d’activités suspectes. Les palourdes Clamav attrapent de plus en plus de virus.

novembre 19, 2018 10:00:00

Lee est caché dans la ville de la Grande Pomme. Il met à jour son laboratoire. Bob retourne là bas pour l’aider et essayer d’avoir des nouvelles de son clan.

novembre 20, 2018 13:00:00

J’ai vu des espions framboise dans la vallée de la silice. Ils sont, pour l’instant, détecté par les suricates.

Mais ça craint quand même.

J’annonce au peuple oiseau 🐦 que je vais bientôt partir. Je leur explique l’usage de MyCrypNet pour me joindre.

novembre 21, 2018 13:00:00

J’ai vu des camps framboise se former sur des îlots 🏝️ au large de la vallée de la silice.

Qu’est ce qu’ils foutent ?

novembre 22, 2018 13:00:00

J’ai demandé aux suricates d’intervenir.

Les suricates disent qu’ils n’interviendront pas. Leur rôle est d’empêcher les intrusions pas plus.

Rhaaaaa…

novembre 23, 2018 13:00:00

Les palourdes rament de plus en plus. Elles sont bourrées de virus.

Elles mettent de plus en plus de temps à les enfouir dans leurs bacs à sable.

novembre 24, 2018 13:00:00

J’attends le message de Lee pour pouvoir partir.

Il est, pour l’instant, le seul à savoir aller au multisite du bouleau.

novembre 25, 2018 13:00:00

NON ! NON ! NON !! Ce que je craignais est arrivé.

Des espions framboises ont passé les suricates et sont tout prêts du village oiseau 🐦.

Troisième mois

novembre 26, 2018 10:00:00

J’entends des bruits. Une équipe de penetration testing des « fruits écrasés » !!!

novembre 27, 2018 13:00:00

Oiseau tonnerre a été blessé après l’attaque d’hier. Il a oublié ses contacts et ses rendez-vous.

novembre 28, 2018 13:00:00

Dav le médecin est venu pour aider Oiseau tonnerre à se rappeler de ses données.

novembre 29, 2018 13:00:00

Dav se sert d’un nuage (cloud) pour que Oiseau tonnerre se rappelle de ses contacts et rendez-vous.

novembre 30, 2018 13:00:00

Dav me dit d’utiliser des éclairs (lightning) avec son nuage pour faire un électrochoc.

Oiseau tonnerre se rappellera peut-être de ses contacts/rendez-vous !

décembre 1, 2018 13:00:00

Oiseau tonnerre revient à lui. Dav me dit : « Synchro effectuée. Le backup est à vérifier. »

Ils m’énervent tous ces spécialistes, lui, le gardien à parler de façon aussi cryptique (on dit pas chiffrique ?)

décembre 2, 2018 13:00:00

Dav a insisté pour que je reste avec Oiseau tonnerre pendant une semaine. Il m’a dit :

« Le full backup est hebdomadaire. Reste pour vérifier les incréments ! »

Bon, je reste une semaine.

décembre 3, 2018 10:00:00

Oiseau tonnerre se repose pendant que je vérifie les réseaux. Je veux savoir comment les redteams des « fruits écrasés » sont arrivés. J’ai un soupçon sur les Wifis.

Incrément 1 de son backup.

décembre 4, 2018 13:00:00

Oiseau tonnerre me raconte des histoires. Ce qui est arrivé après la venue du peuple oiseau🐦 sur Kookati.

Incrément 2 de son backup.

décembre 5, 2018 13:00:00

« Alors que le peuple oiseau🐦 arriva sur la vallée de la silice, il fut poursuivi par les armées des « fruits rouges ». Des insectes bugs, des zombies et les « hommes-framboise » (bits, trames et paquets de Pi-framboise). »

Incrément 3 de son backup.

décembre 6, 2018 13:00:00

« Une grande guerre eut lieu qui déstabilisa le climat du site de la vallée de la silice. Le chef des « fruits écrasés » fit appel à des Botnets entiers du Nanovers pour mener le combat. »

Incrément 4 de son backup.

décembre 7, 2018 13:00:00

« Le chef des fruits affirma que les changements climatiques étaient une fakenews des oiseaux🐦. »

Incrément 5 de son backup.

décembre 8, 2018 13:00:00

« Les oiseaux🐦 fédérèrent les peuples de la vallée de la silice. Avec les suricates, les renifleurs et les palourdes clamav, ils repoussèrent les fruits hors du site. »

Incrément 6 de son backup.

décembre 9, 2018 13:00:00

Oiseau tonnerre ne sait pas où ont pu aller les fruits vaincus et surtout leur chef. Il m’a dit qu’il y avait encore une de leurs bases abandonnées sur le site.

J’irai jeter un oeil.

full backup, Oiseau tonnerre est complètement récupéré.

décembre 10, 2018 10:00:00

Je pars à la recherche de cette base abandonnée. Un oiseau🐦 est avec moi. Il dit qu’il est bon pour chercher des trucs. Il s’appelle Canardcanardva.

En cas d’attaque de « fruits écrasés », j’ai aussi une palourde clamav avec moi.

décembre 11, 2018 13:00:00

Canardcanardva me parle d’un autre chercheur qui s’appelle VouloirQuantité.

Le plus connu des ces chercheurs est 1etcent0.

C’est bien ce qu’il me raconte mais s’il pouvait me dire des trucs intéressants sur cette base abandonnée ce serait mieux.

décembre 12, 2018 13:00:00

Bon, selon les renseignements de Canardcanardva la base abandonnée devait être sur la 404ème route et maintenant y a plus rien.

Bon, ben retour au village. Le mystère reste entier.

décembre 13, 2018 13:00:00

En revenant, j’ai cru voir un drapeau 🏳️ des « fruits écrasés » dans le lointain. Peut-être un reste de la base. Je ne vois aucun moyen d’y accéder.

Il faudra envoyer une équipe rouge. Ces drôles d’oiseaux sont très bons pour faire des tests de pénétrations d’environnement.

décembre 14, 2018 13:00:00

Bon, de retour au village. Tous les oiseaux sont là 🐦.

Oiseau tonnerre, Gazouilleur, Pigeon, le gardien, Canardcanardva, Dav, le chef…

décembre 15, 2018 13:00:00

J’ai expliqué le fonctionnement de MyCrypNet. J’ai fait mes bagages, plié mon garage de développement.

J’y vais.

décembre 16, 2018 13:00:00

Je suis arrivé sur la plage de la Vallée de la Silice pour prendre mon envol.

Les bacs à sable sont pleins, les palourdes clamav aussi. J’ai des remords à quitter les oiseaux maintenant.

Je vois les surfs des « fruits écrasés » au large, pleins d’insectes bugs, de zombies.

décembre 17, 2018 10:00:00

Le chef m’a rejoint sur la plage et m’a dit que je serais plus utile avec Lee.

Il pense que sur le long terme, l’équipe Limawi est notre seul espoir.

Je m’envole. Lee m’a envoyé les coordonnées du site.

décembre 18, 2018 13:00:00

En m’éloignant de l’île, j’ai vu que l’attaque des « fruits rouges » a commencé.

Les zombies, les insectes bugs des fruits ont accosté. Formés en équipe rouge ils pénètrent les murs de feu, suricates et autres…

C’est terrible.

décembre 19, 2018 13:00:00

Je me dirige vers l’archipel du Bouleau, le multisite à tire d’ailes.

Lee m’a demandé comment faire pour renvoyer leur navigateur Renard de feu concentré🦊 sans qu’il se souvienne du chemin.

Je lui ai parlé du multisorties de MyCrypNet.

décembre 20, 2018 13:00:00

Je passe au dessus de la Grande Pomme. Bien haut.

Cette île aussi semble sous domination des fruits. La résistance s’organise au sein des chats🐈 et des lapins🐇 mais elle est encore faible.

Seule la ville Épargnate de 3 résiste encore et toujours à l’envahisseur.

décembre 21, 2018 13:00:00

Je suis la colonne vertébrale backbone de la mer de la toile🕸️.

Je peux voir les navigateurs, surfeurs🏄 dessus et j’aperçois même des sous-marins oignons en dessous de la surface.

décembre 22, 2018 13:00:00

Je commence à apercevoir les brumes de l’archipel. Cela fait un petit moment qu’il n’y a plus de surfs sur la mer de la toile🕸️.

On est hors de portée des fruits. Lee a bien choisi.

décembre 23, 2018 13:00:00

Je survole la brume à la recherche des îles🏝️, sites.

Oh, la brume se découvre et laisse apercevoir l’archipel, multisite. Je vois la future île de MyCrypNet et la grande île de Limawi.

Et le labo de Lee complétement déployé. Ouiiiiii !!!

Premier mois

octobre 1, 2018 11:00:00

Bien arrivé sur ce chantier archéoinformatique ! Il semble prometteur.

octobre 1, 2018 15:00:00

Allez, au boulot ! Tout pleins d’artéfacts à étudier.

octobre 1, 2018 17:00:00

Tiens, mais qu’est ce que c’est ? Un de ces réceptacles à données antiques !!!

octobre 1, 2018 18:05:00

Il faut que j’en parle absolument à Mike

octobre 2, 2018 09:00:00

Bon, on retourne au boulot.

octobre 2, 2018 17:00:00

Hum, il faut que je me méfie d’eux. Je vais commencer à chercher un site oû établir notre base de recherche.

octobre 6, 2018 10:00:00

J’embarque sur la mer de la toile. Le marin est bon, il s’appelle Renard de feu

octobre 6, 2018 17:00:00

Encore deux jours de navigation. Renard de feu m’a parlé de surf aujourd’hui, je sais pas pourquoi.

octobre 8, 2018 11:00:00

Arrivé sur le site de Petit-logiciel. J’explore.

octobre 8, 2018 15:00:00

Pourquoi il y a des post-its de mots de passe pourris partout ? Faut que je fasse quelque chose.

octobre 8, 2018 18:05:00

Bon, je vais leur donner une autre méthode que ces post-its.

octobre 9, 2018 11:00:00

Visiblement c’est pas le bon endroit. Je rembarque pour un autre site via la mer de la toile avec Renard de feu

octobre 9, 2018 13:00:00

Je me pose quand même une question. Qu’est devenu Po ?Il était pas présent avec ses frères.

octobre 9, 2018 17:00:00

Je me demande combien de sites ne dépassent pas de l’eau et sont dans la toile profonde.

octobre 9, 2018 19:00:00

Avec Renard de feu on parle bouffe maintenant.

• Lui : Moi aussi j’aime bien les fruits au sirop.
• Moi : Oh ben cool alors !

Voilà, voilà.

octobre 10, 2018 15:00:00

Bon, je retourne à la Grande Pomme. J’ai oublié de préciser une chose à l’équipe.

Ils sont en train de faire n’importe quoi.

octobre 10, 2018 17:00:00

Des extraits de mes explications ont été diffusés. Ils jettent des masques dans tous les sens.

Il faut que je précise des trucs.

octobre 13, 2018 14:00:00

La traversée est ralentie. La mer est pleine de paquets.

Renard de feu soupçonne une attaque sur le site de la vallée de la Silice.

J’espère que Mike va bien.

octobre 14, 2018 11:00:00

De retour sur le site de la Grande Pomme. Direction le chantier archéoinformatique.

Il faut que je demande un accès au garde à travers le mur de protection du feu.

octobre 15, 2018 09:00:00

Arrivé au chantier archéoinformatique. Allez, je prépare les explications.

octobre 15, 2018 18:05:00

Alors, l’assistance, pourquoi le masque jetable est parfait ?

octobre 16, 2018 11:00:00

Allez, je rembarque. J’ai toujours pas trouvé le site. Il ne faut pas qu’ils soit atteignable par les autres.

Ils ont placardé des affiches sur l’archéochantier. Ils prennent de l’ampleur.

Faut que je me barre.

octobre 16, 2018 15:00:00

Renard de feu m’a parlé d’un multisite. On va y faire un tour.

octobre 17, 2018 17:00:00

On arrive à ce multisite. Il est entouré de brume.

octobre 20, 2018 15:00:00

Ok, je vais voir quelques sites de cet archipel multisite.

octobre 20, 2018 16:00:00

Dans cette brume, une grande île. 🏝️ Un grand site. Je vais voir pour établir la base de recherche ⚗️<

octobre 21, 2018 11:00:00

Je vais m’assurer des accès quand même.

octobre 22, 2018 15:00:00

Des accès à double authentification… Cool !!!

octobre 22, 2018 17:00:00

Je vais expliquer ce que c’est alors.

octobre 22, 2018 18:05:00

Alors, la double authentification c’est quoi ?

octobre 23, 2018 17:00:00

Bon, ce coin me paraît bien. Je vais envoyer un message avec le masque jetable à Mike.

Faut que je me calme quand même, j’ai plus beaucoup de clés.

octobre 24, 2018 15:00:00

Allez, retour au chantier archéoinformatique. J’ai du boulot.

Je dois étudier les artéfacts de ce chantier, c’est ce qu’on m’a demandé.

octobre 27, 2018 11:00:00

Quelqu’un a trouvé un autre réceptacle à données.

Il est inaccessible pour l’instant.

octobre 27, 2018 15:00:00

Ça y est je l’ai. Le contenu est chiffré. Hum…

octobre 28, 2018 16:00:00

Ah j’ai compris le chiffrement. Oulà c’est antique !! C’est le cas de le dire.

octobre 28, 2018 18:00:00

Mike m’a dit qu’il avait aussi trouvé un artéfact. Je l’attend toujours.

Deuxième mois

octobre 29, 2018 10:00:00

Bon, une petite explication s’impose. C’est un vieux chiffrement 🔐 historique. On dit que César l’aurait utilisé, enfin, on dit quoi…

octobre 30, 2018 14:00:00

Je suis arrivé au sein du clan des chats dans la ville de la Grande Pomme. Les macHat il s’appellent.

Ils fabriquent des chapeaux 🎩 et autres vêtements. Il faut que je les étudie un peu pour comprendre pourquoi ce vieil indice m’indique d’aller les voir.

octobre 31, 2018 14:00:00

• Le chef des chats 😾 : Tu es du clan macWindows. Que viens-tu faire ichi ?
• Moi : Oh, j’en suis parti tôt. Je ne suis pas au courant des relations entre clans.
• Le chef des chats 😾 : Cha ne répond pas à ma quechtion. Que viens-tu faire ichi ?

Tendue cette entrevue.

novembre 1, 2018 14:00:00

Au fait, le chef du clan s’appelle Astrophe. Je lui dis que selon l’indice il faut que je trouve un chat qui aurait des troubles du sommeil, qui dort, qui ait un rapport avec le sommeil…

Vachement précis comme indice.

Mais il a l’air d’avoir une idée 😼

novembre 2, 2018 14:00:00

Astrophe m’emmène voir un chat particulier. Il s’appelle Bob. Bizarre comme nom de chat.

Je suis encore dans le quartier des chats 🐈. certains d’entre eux ont des comportements bizarres.

Je crains que les chats soient infiltrés par des fruits aplatis.

Faut que je me casse…

Quand on arrive chez lui, Bob est en train de dormir 🛌

Le chef me déconseille de le réveiller sinon il est très grincheux.

Hum, ça correspond bien à l’indice.

novembre 3, 2018 14:00:00

Réveillé en sursaut par Astrophe. Je vois Bob en train de me dévisager 🐱

• Moi : Mmmm… (pas encore bien réveillé) 😴
• Bob (en langue chat) : Le chef m’a expliqué que vous me cherchiez.
• Moi : Mmmmm… 😴
• Bob : Vous parlez bien le chat. Oui, je suis technicien.

novembre 4, 2018 14:00:00

De retour sur le chantier avec Bob qui passe pour mon technicien. La plupart du temps c’est ses ennemis chiens 🐕 donc c’est bizarre…

Je prépare mon labo ⚗️ de recherche Je l’ai appelé Limawi, mon nom quoi.

Il aura aussi le blason familial comme logo

novembre 5, 2018 10:00:00

Un gang de fruits rouges a encore pénétré le chantier durant mon absence. Ils y ont mis plein d’artéfacts foireux. On n’est plus sûr que ce qu’on trouve soit réellement du site.

Je vais devoir expliquer à l’équipe comment s’en assurer.

novembre 6, 2018 14:00:00

Bon ce deuxième indice maintenant. Après les chats 🐈, les lapins 🐇. je vais aller dans la campagne de la Grande Pomme au village lapin de Mixo-mato.

Mais d’abord, il faut que je dise à Bob d’aller voir Mike

novembre 7, 2018 14:00:00

De retour à la Grande Pomme dans le quartier des chats 🐈. Je vais les rassurer.

Oui, Bob est en déplacement vers la vallée de la silice qui est régulièrement attaquée…

Mais il sera protégé par Mike, un oiseau 🐦 de 50g.

Euh… Je pense les avoir rassurés.

novembre 8, 2018 14:00:00

Je suis encore dans le quartier des chats 🐈. Certains d’entre eux ont des comportements bizarres.

Je crains que les chats soient infiltrés par des fruits aplatis.

Faut que je me casse…

novembre 9, 2018 14:00:00

Je suis hébergé juste en dehors du quartier des chats 🐈. Ça commence à chauffer.

Les fruits rouges s’approchent. Je dois prévenir Bob mais là je peux rien faire.

novembre 10, 2018 14:00:00

Le pouvoir a basculé parmi les chats 🐈. Je me casse en campagne.

Il faut que je trouve ce lapin 🐇.

novembre 11, 2018 14:00:00

J’ai passé le mur de feu de la ville de la Grande Pomme. Je commence à m’enfoncer dans la campagne.

Je vais longer le territoire des Épargnates 💪 et ses ruines.

novembre 12, 2018 10:00:00

Un autre archéochantier de l’ancien territoire Épargnate. Ça me rappelle ces variantes d’algorithmes historiques.

novembre 13, 2018 14:00:00

En plein territoire Épargnate. Il y a de gros doutes sur leur allégeance aux baies rouges. Silence radio jusqu’au territoire lapin🐇.

novembre 14, 2018 14:00:00

…—…

novembre 15, 2018 14:00:00

Arrivé dans la ville lapin de Mix-mato. Je vais voir leur chef Kaja 🐰.

Kaja 🐰 m’a dit qu’il y avait une scientifique qui pourrait m’aider.

Elle s’appelle Alice. Nom peu courant pour un lapin🐇.

novembre 16, 2018 14:00:00

J’ai des échos inquiétants provenant de l’archéochantier. Ils se demandent où je suis passé et pourquoi je m’absente si souvent.

J’ai peur que le chantier ait aussi basculé. Est-ce que je dois y retourner ?

Rhaaaaa…

novembre 17, 2018 14:00:00

Il y a de plus en plus de framboises partout sur le site.

J’ai la confirmation que les Épargnates les ont rejoints.

Et ils portent très mal leur nom. Ils n’épargnent personne.

Je fais quoi, je fais quoi ?… Calme, calme…

novembre 18, 2018 14:00:00

Bon, je retourne pas sur le chantier, c’est mort. Je vais me cacher dans la ville de la Grande Pomme avec Alice.

Le temps que je termine mes préparatifs ⚗️ et après direction le multisite.

On servira à rien ici. Il faut mener le projet à terme. C’est notre seul espoir !

novembre 19, 2018 10:00:00

Bon allez au boulot, ça urge. Le labo ⚗️ faut que je l’adapte. Il faut que je le rende plus facile encore à transporter, que je le modernise.

Mise à jour, quoi !

novembre 20, 2018 14:00:00

Bob est rentré hier de la vallée de la silice.

J’ai logé Alice et Bob séparément dans la cachette. Il semble qu’il y ait des tensions entre le clan des macHat 🐈 et celui des macArotte 🐇.

Il semble que les macArotte soient tombés aussi sous la coupe de fruits.

novembre 21, 2018 14:00:00

Leur chef a établi son QG ici. Il organise, il ordonne d’ici, la ville de la Grande Pomme. L’atmosphère de la ville devient de plus en plus étouffante.

Dentbleue qui s’occupait de gérer la ville, de relier les gens entre eux, a été détroné.

novembre 22, 2018 14:00:00

J’ai entendu une rumeur comme quoi les chats 🐈 étaient maintenant forcés de ne fabriquer leurs vétements qu’avec des fibres de framboises et les lapins 🐇 de ne cultiver que de la framboise.

Ça va trés mal. Bob et Alice sont inquiets.

novembre 23, 2018 14:00:00

J’ai aperçu un membre du clan macOs roder autour de la cachette. Ils ne nous a pas repéré. Ce clan de chiens 🐕 a été infiltré par les framboises mais ces technichiens cachent autre chose.

Je sais pas ce que c’est.

novembre 24, 2018 14:00:00

—…—, oups, …—…

novembre 25, 2018 14:00:00

Bon, il faut que je réflechisse comment dire à Bob et Alice ce que j’attend d’eux et toutes ces histoires d’indices.

Leurs clans respectifs peuvent pas se sentir. C’est pratique…

Allez, grande réunion demain.

Troisième mois

novembre 26, 2018 10:00:00

La réunion commence. Bob et Alice sont là. Mes futurs DevSecOps. On va reprendre un peu les bases de la cryptographie.

novembre 27, 2018 14:00:00

La ville de la Grande Pomme est entièrement bloquée. C’est la grande conférence des Épargnates. En plus, les « fruits écrasés » s’en mêlent. Leur chef est là, plein de fakenews, très doué en ingénierie sociale.

novembre 28, 2018 14:00:00

Je sais pas combien de temps la quarantaine de la ville va durer. On a une armée d’insectes bugs des «fruits rouges» qui patrouille dans les rues et entre dans les immeubles en brute force.

novembre 29, 2018 14:00:00

On essaie d’améliorer la portabilité du laboratoire Limawi Alice fait de l’amélioration continue de nos systèmes.

novembre 30, 2018 14:00:00

On coupe les réseaux actuels du labo pour diminuer nos traces.

Bob teste les systèmes proprement virtualisés du laboratoire. Ça augmente considérablement la portabilité.

décembre 1, 2018 14:00:00

On va pouvoir sortir le labo de l’immeuble en petits paquets. J’explique à Alice et Bob comment mieux renforcer leurs phrases de passe, l’environnement est moins sûr.

décembre 2, 2018 14:00:00

Oh oh !!!

Faut qu’on se barre. J’ai vu leur pentesteur qui essaie de pénétrer dans l’immeuble. On est repéré.

décembre 3, 2018 10:00:00

Pour les réseaux, on a MyCrypNet pour sécuriser les accès au laboratoire sur les Wifi publics donc on gagne en adaptabilité.

décembre 4, 2018 14:00:00

On a mis nos appareils dans du papier d’alu et dans le minibar de notre chambre. On diminue les risques d’être détectés.

On a pris qu’une seule chambre et payé en cryptocoins.

décembre 5, 2018 14:00:00

Les pentesteurs et les redteams des « fruits écrasés » patrouillent partout dans la ville de la Grande Pomme. Ils cherchent le moindre drapeau à capturer CTF.

Pour passer le temps, flashback sur l’histoire de la cryptographie dans mon labo : Le Carré de Polybe

décembre 6, 2018 14:00:00

Deux tiers des Épargnates les ont officiellement rejoints. Il ne reste plus que la ville de 3 et leur chef Joule César qui résistent.

Quand je pense à un de leurs chiffrements ROT13, je rigole. Oh un flashback dans mon labo !!

décembre 7, 2018 14:00:00

Le bar clandestin dans lequel nous sommes est dans le quartier des macWindows, mon quartier d’origine.

Je n’ai aucune information sur les relations du clan avec les « fruits écrasés », on reste donc discret.

décembre 8, 2018 14:00:00

Bob peut voir le quartier des chats, les macHats, depuis la chambre.

Les pentesteurs, les redteams, les insectes bugs et les zombies des fruits patrouillent en permanence. Il ne peut rien faire.

décembre 9, 2018 14:00:00

J’ai un contact dans le bar avec un surfeur. Il s’appelle Renard de feu concentré 🦊 et est un cousin de Renard de feu.

décembre 10, 2018 10:00:00

On embarque sur le surf de Renard de feu concentré🦊. Il a une palourde clamav avec lui. On est d’accord que ce n’est plus suffisant comme seule cybersécurité.

décembre 11, 2018 14:00:00

Alice et Bob ont discuté un peu seuls. S’éloigner de la Grande Pomme leur fait du bien.

décembre 12, 2018 14:00:00

Renard de feu concentré🦊 me fait visiter son surf. C’est un bon navigateur, beaucoup plus mobile que son cousin.

Il me dit que son surf peut passer sous les radars grâce à des antitraqueurs.

Je le savais déjà. C’est pour ça que j’ai fait appel à lui.

décembre 13, 2018 14:00:00

On est à mi-chemin de l’archipel. On suit une gigantesque colonne vertébrale backbone au fond de la mer de la toile🕸️. C’est flippant.

Qu’est-ce qui se passe sous ces eaux, dans la toile profonde deepweb ? Et au fond, où la lumière ne passe plus, la toile sombre darkweb ?

décembre 14, 2018 14:00:00

Renard de feu concentré🦊 m’explique que de temps en temps il aide dans des safaris à ne pas se faire pister.

Je ne sais pas quoi en penser. Je m’enferme dans ma chambre et rêve encore d’histoire de la cryptographie.

Flashback dans mon labo : le chiffre de Beaufort.

décembre 14, 2018 14:30:00

Tiens, un deuxième flashback : la variante allemande du chiffre de Beaufort.

décembre 15, 2018 14:00:00

Alice et Bob travaillent sur les indices. Il s’échangent des messages chiffrés avec le masque jetable pour que Renard de feu concentré🦊 ne comprenne pas.

C’est un peu stupide vu qu’ils sont sur le même surf.

Enfin, c’est mignon.

décembre 16, 2018 14:00:00

On approche de l’archipel dans la brume. Il faut que je trouve un moyen pour que Renard de feu concentré🦊 ne se souvienne pas nous avoir emmener là.

décembre 17, 2018 10:00:00

L’archipel, le multisite du Bouleau est devant nous.

Bon, comment effacer à coup sûr le trajet de la mémoire de Renard de feu concentré🦊. Jeter la carte du trajet à la poubelle ce n’est pas suffisant.

décembre 18, 2018 14:00:00

On descend l’équipement du surf sur l’île🏝️ principale, le site principal. Bob et Alice déploient le laboratoire et l’intègrent à l’environnement.

Je plante le drapeau de Limawi 🏳️ J’espère que les « fruits écrasés » ne le captureront pas CTF.

décembre 19, 2018 14:00:00

J’ai réduit en cendres, shred wipe les cartes du trajet sur le surf de Renard de feu concentré🦊

Je les ai réduits 50 fois pour être sûr.

Je lui ai fait un nettoyage de sa mémoire récente quand il dormait.

décembre 20, 2018 14:00:00

Mike m’a dit comment paramétrer un réseau MyCrypNet pour de multiples sorties.

J’envoie Renard de feu concentré🦊 encore dormant sur son surf par l’une de ces sorties.

décembre 21, 2018 14:00:00

Mike m’a annoncé qu’il commence à approcher de l’archipel. Il peut naviguer plus facilement sur la mer de la toile avec son accès MyCrypNet.

Alice empile des boîtes virtuelles Virtualbox 📦 dans lesquelles elle mène ses expériences.

décembre 22, 2018 14:00:00

Alice utilise une coquille🐚 pour ses expériences. Elle a renforcé sa shell🐚 avec un outil qui permet de la frapper bash.

Bob structure les outils du labo entre eux. Il supervise (voire même hypervise) les relations entre boîtes virtuelles et les machines virtuelles à noyau.

décembre 23, 2018 14:00:00

Bon, il y a plusieurs environnements sur ce site. Alice s’est installée dans l’un deux et continue de rechercher. Bob est installé dans un autre et continue d’intégrer.

J’ai retrouvé ma scytale dans mes bagages et mon labo est de nouveau debout.

Surface d’attaque

Il suffit d’avoir accès au panneau d’authentification qui permet de taper le mot de passe administrateur. Ce panneau est accessible depuis n’importe quel compte sur l’appareil (en local ou à distance avec des protocoles de prise en charge comme VNC).

La faille provient de l’activation par erreur du compte root sur la version MacOS High Sierra. Ce compte root est un héritage du système UNIX sur lequel MacOS est développé. Il est présent et utilisé dans le monde Linux mais est normalement désactivé (présent mais désactivé) sur Mac au profit de comptes administrateurs spécifiques qui ne peuvent pas changer les fichiers du système.

Comment se protéger

Il suffit de donner un mot de passe à ce compte root. Ne perdez pas ce mot de passe.

En lignes de commandes depuis n’importe quel compte administrateur de l’appareil

• Ouvrez votre terminal. L’application est présente dans votre dossier Applications & Utilitaires.
• Tapez la ligne de commande suivante puis faites Entrée: sudo passwd -u root
• Un mot de passe vous sera demandé, tapez le mot de passe de votre compte root puis faites Entrée.
• Tapez le même mot de passe pour le confirmer et faites Entrée à nouveau.
• Votre compte root est configuré avec un mot de passe.

Par l’interface graphique

• Allez au menu > Préférences système.
• Cliquez sur Utilisateurs et Groupes (ou Comptes).
• Cliquez sur le cadenas, puis entrez un nom et son mot de passe administrateur.
• Cliquez sur Options d’ouverture de session.
• Cliquez sur Rejoindre ou Modifier.
• Cliquez sur Utilitaire d’annuaire.
• Cliquez sur le cadenas dans la fenêtre de l’utilitaire, puis entrez un nom et mot de passe administrateur.
• Dans la barre de menu de cet Utilitaire d’annuaire, choisissez Édition & Modifier le mot de passe root…
• Entrez un mot de passe root quand demandé.

Le WPA2 est le protocole d’authentification des réseaux WI-FI qui était considéré comme sûr jusqu’à présent et qui remplaçait, depuis 2004, le protocole WEP (percé en 2001). Il est le standard de sécurité des réseaux WI-FI protégés du monde entier.

Surface d’attaque

La surface d’attaque de ce moyen est limitée et peut être réduite. Tout d’abord, l’attaquant doit se trouver à portée du signal du WI-FI pour effectuer l’attaque.

Ensuite, l’attaque concerne le mécanisme d’authentification du WI-FI. Elle ne remet pas en cause la sécurité des données stockées sur les appareils. Les données potentiellement vulnérables sont celles qui circulent sur le réseau WI-FI entre les appareils et la borne.

Cette attaque se sert de l’authentification WPA2 comme porte d’entrée mais elle repose sur une faille du système WI-FI lui-même. WPA2, même parfaitement implémenté, ne peut rien contre cette faille. C’est le système WI-FI qu’il faut patcher.

Simplement expliqué, le WI-FI permet de renvoyer des paquets de données parfaitement identiques à la borne qui les traitent sans discernement.

L’attaquant s’appuie là-dessus pour renvoyer les clés d’authentification à la borne depuis son appareil à la place de la victime.

La borne, ne distinguant pas l’envoi du réenvoi, valide l’authentification avec les mêmes clés dans les deux cas. L’attaquant possède donc les mêmes clés de déchiffrement que la victime lui permettant de déchiffrer les échanges entre la victime et la borne.

Comment se protéger

Il y a plusieurs façons de se protéger.

Les mises à jours

Tout d’abord, vérifiez si des mises à jours de sécurité sont disponibles pour vos appareils. Voici la liste des systèmes bénéficiant d’une mise à jour par ZDNet (en anglais). Une politique de mise à jour régulière de vos appareils est à envisager pour être paré contre des attaques futures.

La réduction de la surface d’attaque

Ensuite, veillez à réduire la surface d’attaque. Mettez sur câble ethernet le maximum d’appareils possible et coupez leur WI-FI. Pas de WI-FI, pas d’attaque possible.

Le remplacement du chiffrement

Pour les appareils ne pouvant se connecter que par WI-FI, il faut palier aux failles du chiffrement du protocole WPA2 par un autre chiffrement.

Visitez vos sites web en https, le protocole de chiffrement associé (le ’s’ de https comme sécurité) remplace la défaillance de WPA2 pour les communications site par site. Une extension de navigateur comme HTTPS everywhere peut vous aider.

Installez un VPN sur vos appareils. Il chiffre la totalité du flux entre vos appareils et le WI-FI (et au delà sur Internet). Je vous conseille bien sûr notre service, MyCrypNet, qui a pour avantage supplémentaire de renforcer les fonctionnalités de votre réseau en l’abstrayant des considérations géographiques.

SSL/TLS est un protocole qui permet de vérifier l’identité d’un serveur (par exemple un serveur web comme Limawi, dans ce cas on parle d’https car le protocole d’accès à un serveur web s’appelle http). Cette vérification d’identité fonctionne avec un envoi de certificat de la part du serveur.

Voici le protocole étape par étape (les termes techniques sont présents dans les infographies) :

• Le client demande au serveur son identité
• Le serveur envoie au client son certificat signé par une autorité de confiance commune au client et au serveur
• Le client vérifie que la signature appartient bien à une autorité de confiance qu’il reconnaît
• Il envoie une demande à cette autorité de confiance pour déterminer si elle considère ce certificat encore valable
• Le client et le serveur se mettent d’accord sur une clé de session qui chiffrera les informations pendant un temps limité (ce temps révolu, une autre clé de session prend le relais, le détail pour Limawi est expliqué dans l’infographie sur la clé de session)
• Le client et le serveur peuvent communiquer de façon sécurisée

L’extension HSTS

L’extension HSTS est une extension du protocole http (le protocole qui charge des pages web) renforçant l’usage de SSL/TLS.

Cette extension force un navigateur à charger les versions sécurisées d’une page et de toutes les ressources que cette page contient (c’est à dire les versions https) sur un domaine (l’adresse de base d’un site web) qui l’implémente.

Si la page recherchée n’a pas de version sécurisée, elle n’est pas chargée par le navigateur.

Une fois que le navigateur a accédé au site utilisant cette extension il garde en mémoire que les prochaines pages visitées sur ce site doivent être sécurisées. Il peut ainsi le vérifier avant même d’envoyer la requête au site.

Une extension HSTS est valable pour une durée limitée et le navigateur doit vérifier au bout de cette validité si le site l’utilise toujours pour déclencher une nouvelle période de validité.

Les domaines (l’adresse de base d’un site web) peuvent être préchargés dans une base de données disponible dans votre navigateur. Ainsi le navigateur sait avant même d’envoyer la première requête de son historique à une page qu’elle doit être sécurisée sinon il ne la charge pas.

Cette base est disponible ici : HSTS Preload.

Chez Limawi

Pour Limawi, l’autorité de certification est Let’s Encrypt.

L’échange de la clé de session entre le client et le serveur se fait grâce au protocole Diffie-Helman qui permet de créer une clé symétrique de session sans échanger d’éléments secrets.

Limawi utilise HSTS. La validité de l’HSTS est de 6 mois.

Références

• SSL/TLS : Wikipedia
• HSTS : Wikipedia
• Diffie-Helman : Wikipedia
• Préchargement pour Limawi : Préchargement HSTS