Utilisation de openSSL pour échanger de manière sécurisée

Dans cet exercice, vous allez effectuer un échange sécurisé d’informations grâce à des opérations de chiffrement et de déchiffrement symétriques et asymétriques. Ces opérations manuelles sont complexes, coûteuses en temps et sujettes à erreur. D’où la nécessité de disposer d’une infrastructure de gestion de clés (PKI)

Préparation

  • Vous aurez besoin d’une machine virtuelle Linux (type Debian par exemple)
  • Dans le répertoire /home de stagiaire, créer 3 sous dossiers : « /home/alice », « /home/bob » et « /home/ac »

Etape 1 : génération des clés cryptographiques et certificats

Étape 1.a – Alice génère une clé privée

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:3 -out privkey-A.pem
  • genpkey ➝ génère une clé privée
  • -algorithm RSA ➝ utilise l’algo RSA (peut aussi accepter “EC” pour courbes elliptiques)
  • -pkeyopt opt:value ➝ permet de donner une valeur optionnelle (voir ci-dessous)
  • rsa_keygen_bits:2048 ➝ définit la taille de la clé à 2048 bits (le défaut est à 1024)
  • rsa_keygen_pubexp:3 ➝ exposant public « e » à 3 (défaut est 65, 537)
  • -out privkey-A.pem ➝ ecrit le fichier de sortie privkey-A.pem

Étape 1.b – Alice génère une clé publique

openssl pkey -in privkey-A.pem -pubout -out pubkey-A.pem
  • pkey ➝ process la clé publique ou privée
  • -in privkey-A.pem ➝ lit la clé depuis le nom de fichier privkey-A.pem
  • -pubout ➝ génère une clé publique (par défaut, la sortie est une clé privée)

Optionnel : visualisation des clés en clair

Les clés sont enregistrées en base64 et ne sont pas lisibles si vous les ouvrez dans un éditeur de texte ou dans le terminal. Heureusement, openssl nous fournit un ensemble de commandes pour les convertir en texte. Le flag (-noout) empêche également la commande d’imprimer l’encodage base64.

openssl pkey -in privkey-A.pem -text -noout
openssl pkey -pubin -in pubkey-A.pem -text -noout

Notez la différence de taille entre la clé privée et la clé publique (l’une est un sous-ensemble de l’autre). Il y a quelques valeurs supplémentaires stockées dans la clé privée que vous ne reconnaîtrez pas (exposant1, exposant2 et coefficient). Ceux-ci sont stockés par openssl pour accélérer le déchiffrement.

Étape 1.c – Alice génère une demande de signature de certificat

openssl req -new -key privkey-A.pem -out A-req.csr
  • req ➝ crée et gère une CSR (Certificate Signing Request
  • -new ➝ génère une nouvelle CSR, va demander des informations à Alice
  • -key privkey-A.pem ➝ Signe la requête avec la clé privée d’Alice

La commande posera ces questions à Alice :

  • Code pays [C]
  • Nom de la province/État [ST]
  • Ville/Lieu [L]
  • Nom de l’organisation [O]
  • Nom de l’unité organisationnelle [UO]
  • Common Name [CN]
  • Adresse email
  • Un mot de passe de challenge []

Étape 1.d – L’AC génère et signe un certificat pour Alice

Générer un certificat auto-signé pour l’AC

Répéter les étapes 1a et 1b pour l’AC (dans le crépertoire de l’AC), en adaptant les noms de fichier, puis générer un certificat auto-signé d’AC avec la commande suivante:

openssl req -x509 -new -nodes -key privkey-AC.pem -sha256 -days 1024 -out AC.crt

L’AC génère et signe un certificat pour Alice

openssl x509 -req -in A-req.csr -CA ../ac/AC.crt -CAkey ../ac/privkey-AC.pem -CAcreateserial -out A.crt -days 500 -sha256
  • x509 ➝ un utilitaire de certificat x509 (affiche, convertit, édite et signe les certificats x509)
  • -req ➝ une demande de certificat est prise en entrée (la valeur par défaut est un certificat)
  • -CA root.crt ➝ spécifie le certificat CA à utiliser comme émetteur du certificat d’Alice
  • -CAkey rootkey.pem ➝ spécifie la clé privée utilisée dans la signature (rootkey.pem)
  • -CAcreateserial ➝ crée un fichier de numérique contenant un compteur du nombre de certificats qui ont été signés par cette autorité de certification
  • -days 500 ➝ fait expirer le certificat d’Alice dans 500 jours
  • -sha256 ➝ spécifie l’algorithme de hachage à utiliser pour la signature du certificat

Optionnel: afficher le certificat sous forme de texte

openssl x509 -in Alice.crt -text -noout

Etape 2 : Alice tente de chiffrer un fichier avec la clé publique : Echec !

Étape 2.a – Alice vérifie le certificat public de Bob

Attention : ne pas oublier de répéter pour Bob les actions faites pour Alice :

openssl req -new -key privkey-B.pem -out B-req.csr
openssl x509 -req -in B-req.csr -CA ../ac/AC.crt -CAkey ../ac/privkey-AC.pem -CAcreateserial -out B.crt -days 500 -sha256

Puis Alice peut vérifier le cert de Bob

openssl verify -CAfile ../ac/AC.crt ../bob/B.crt

Étape 2.b – Alice extrait la clé publique de Bob

openssl x509 -pubkey -in ../bob/B.crt -noout > pubkey-B.pem

-pubkey ➝ affiche la clé publique du certificat (au format PEM)

Étape 2.c – Alice essaie de chiffrer son fichier largefile.txt avec la clé publique de Bob

Si besoin de générer un fichier aléatoire largefile.txt de 10 MB, utiliser cette commande :

head -c 10M </dev/urandom > largefile.txt

puis :

openssl pkeyutl -encrypt -in largefile.txt -pubin -inkey pubkey-B.pem -out ciphertext.bin
  • pkeyutl ➝ utilitaire pour effectuer des opérations de clé publique
  • -encrypt ➝ chiffre les données d’entrée
  • erreur ! (rappel : RSA n’est pas destiné à chiffrer des fichiers volumineux – Alice doit utiliser le chiffrement à clé symétrique pour cela)

Etape 3 : Génération de clé symmétrique, chiffrement et envoi

Étape 3.a – Alice génère une clé symétrique

openssl rand -base64  -out symkey.pem 32

Étape 3.b – Alice chiffre symkey.pem en utilisant la clé publique de Bob

openssl pkeyutl -encrypt -in symkey.pem -pubin -inkey pubkey-B.pem -out symkey.enc

Étape 3.c – Alice hache symkey.pem et le chiffre à l’aide de sa clé privée

openssl dgst -sha1 -sign privkey-A.pem -out signature.bin symkey.pem
  • dgst -sha1 ➝ hacher le fichier d’entrée en utilisant l’algorithme sha1
  • -sign privkey-A.pem ➝ signe le hachage avec la clé privée spécifiée
  • symkey.pem ➝ le fichier d’entrée à hacher

Etape 4 : Réception de la clé symétrique et vérification

Étape 4.a – Bob déchiffre symkey.enc en utilisant sa clé privée

(d’abord, copier symkey.enc et signature.bin dans le répertoire bob pour simuler l’envoi depuis Alice vers Bob)

openssl pkeyutl -decrypt -in symkey.enc -inkey privkey-B.pem -out symkey.pem

Étape 4.b – Bob obtient et vérifie le certificat d’Alice et extrait sa clé publique

Ceci est simplement une répétition de ce qu’Alice a fait à l’étape 2b, mais cette fois-ci pour Bob :

openssl x509 -pubkey -in ../alice/A.crt -noout > pubkey-A.pem

Étape 4.c – Bob vérifie que le message provient d’Alice

openssl dgst -sha1 -verify pubkey-A.pem -signature signature.bin symkey.pem
  • -verify pubkey-A.pem ➝ vérifie la signature en utilisant le nom de fichier spécifié
  • -signature signature.bin ➝ spécifie la signature à vérifier
  • symkey.pem ➝ le fichier à hacher

Etape 5 : Echange de message sécurisé

Étape 5.a – Alice chiffre son largefile.txt avec la clé symétrique

openssl enc -aes-256-cbc -pass file:symkey.pem -p -md sha256 -in largefile.txt -out ciphertext.bin
  • enc -aes-256-cbc ➝ chiffrer un fichier à l’aide de l’algorithme à clé symétrique aes-256-cbc
  • -pass file:symkey.pem ➝ spécifie le fichier à partir duquel obtenir la clé symétrique
  • -p ➝ imprime la clé, le sel, le vecteur d’initialisation à l’écran
  • -md sha256 ➝ utilise sha256 dans le cadre de la fonction de dérivation de clé (une fonction qui dérive une ou plusieurs clés secrètes secondaires à partir d’une clé secrète primaire)

Étape 5.b – Bob déchiffre ciphertext.bin avec la même clé symétrique

(d’abord, copier ciphertext.bin dans le répertoire bob pour simuler l’envoi depuis Alice vers Bob)

openssl enc -aes-256-cbc -d -pass file:symkey.pem -p -md sha256 -in ciphertext.bin -out largefile.txt

-d pour déchiffrer

Scrum, temps passé en réunions et vélocité

Récemment, je discutais avec un client et il m’expliquait que depuis que l’équipe est passée à Scrum, le temps passé en réunions a augmenté et la vélocité a diminué. D’un autre côté, les équipes apprécient beaucoup le « backlog grooming » car cela leur permet de mieux comprendre le sens de leur travail ainsi que la vision du produit (à ce sujet n’hésitez pas à (re)lire l’article sur l’objectif de sprint).

Alors, doit-on s’inquiéter d’une perte de productivité lors d’un passage à Scrum? Passer à Scrum est-il forcément synonyme de « réunionite aigüe »?

les réunions dans Scrum

Scrum et le temps passé en réunion

Penser que l’on passe trop de temps en réunion est une notion subjective. Or, il est facile de mesurer le temps qu’une équipe scrum devrait passer en réunions en théorie, alors pourquoi rester sur une impression? Pour un sprint de 1 mois ça donne:

  • Sprint planning : 8h maxi
  • Revue de sprint : 4h maxi
  • Daily Scrum: 15mn maxi x20 jours = 5h
  • Rétrospective: 3h maxi
  • Backlog grooming: 10% de la capacité mais c’est peut être un peu trop. Disons 8h (2h/semaine).

Cela nous fait un total de 28h, soit 18.6% de la capacité. Il faut savoir qu’une moyenne de 20% du temps passé en réunions est courant en Scrum. Ces événements sont les seuls nécessaires pour que l’équipe soit en mesure de délivrer. Voici ce que vous pouvez faire pour optimiser cet aspect de votre activité:

  • Mesurer le temps réellement passé en réunions (le Scrummaster peut se charger de consolider)
  • Examiner en rétrospective les raisons possibles si cela prend plus de temps (laisser l’équipe s’améliorer). Ces événements sont limités dans le temps (time boxed), donc il est nécessaire d’aider l’équipe à respecter les durées maxi. Quelques raisons possibles de dépassement : 
    • On fait les réunions Scrum EN PLUS d’autres réunions traditionnelles (restes de waterfall, etc)
    • Des personnes sont à cheval sur plusieurs équipes (et donc multiplient les réunions)
    • Les réunions ne sont pas assez préparées à l’avance
    • Une culture d’entreprise propice aux réunions

La vélocité de l’équipe Scrum

La vélocité est un outil qui permet de mesurer la capacité d’une équipe à délivrer de la valeur dans le temps. Il arrive qu’il serve d’outil de mesure de productivité destiné au management (à tord ou pas, là n’est pas la question), mais cela peut être trompeur.

Il n’est pas rare qu’elle varie dans le temps: augmentation durant les premiers sprints, puis stagnation, voire diminution si le cycle de développement du produit passe par des défis techniques, ou de la dette technique à résorber.

Evitez aussi de comparer la vélocité entre équipes. Comme c’est basé sur des estimations en story points, chaque équipe a ses références et la valeur d’un SP n’est pas la même d’une équipe à une autre. Que mesurer en plus de la vélocité pour avoir une vision globale? Quelques exemples :

Ces indicateurs vont permettre de voir si la baisse de vélocité se fait en gagnant sur d’autres points (qualité, motivation etc), ou si elle est due à ces mêmes points qui se sont dégradés. Là encore, si problème il y a, ce sera à l’équipe d’aborder le point en rétrospective et à trouver une solution. Si elle y parvient, elle fera un pas de géant en termes de maturité, de cohésion et de solidarité.
Pour régler un problème en rétrospective, je conseille généralement ces 4 étapes :

  • Etat des lieux du problème (avec métriques)
  • Lister toutes les options possibles pour améliorer la situation (au moins 3)
  • En choisir une et la mettre en œuvre
  • Evaluer le résultat et adapter

Et vous? Avez-vous l’impression que le passage à Scrum a dégradé certains indicateurs de performance? Vous avez l’impression d’enchaîner les réunions? Votre productivité semble avoir baissé? Comment avez-vous géré la situation? N’hésitez pas à partager vos commentaires!

Déployer une PKI: Pourquoi et comment (3ème partie)

Si vous n’avez pas lu les 2 premiers articles de la série, n’hésitez pas à faire un tour ici et ici. Sinon, vous savez déjà qu’un projet de déploiement de PKI n’est pas que technique. Bienvenue pour ce dernier article de la série « Déployer une PKI ». Aujourd’hui, nous allons parler des 2 dernières étapes d’un projet de déploiement: le paramétrage et l’audit.

certificat numérique
Continuer la lecture de « Déployer une PKI: Pourquoi et comment (3ème partie) »

Déployer une PKI: Pourquoi et comment (2ème partie)

Dans l’épisode précédent…

Dans le précédent article, nous avons vu que la PKI a rendu le chiffrement, la signature et l’authentification transparentes pour les utilisateurs. Elle permet la gestion et la protection de certificats numériques. Le tout en vue de protéger l’information dématérialisée (chiffrement, signature, authentification, etc).

pki puzzle

Nous avons aussi vu la première étape d’un projet de déploiement d’une Infrastructure de Gestion de Clés: L’analyse et la conception. Durant cette étape, on apporte la réponse aux questions liées aux usages de la PKI, à la documentation qui sera mise en place, aux coûts, sécurité, architecture etc.

Voyons maintenant l’étape suivante:

Continuer la lecture de « Déployer une PKI: Pourquoi et comment (2ème partie) »

Déployer une PKI: Pourquoi et comment (1ère partie)

Cet article est le premier d’une série visant à aider le lecteur en vue d’un projet de déploiement d’une Infrastructure à Clés Publiques (PKI)

PKI

Introduction et définitions

Depuis toujours il a été nécessaire de protéger des informations sensibles. Il peut s’agir d’informations confidentielles qui ne doivent être connues que par certaines personnes. Mais aussi il y a ce besoin de garantir la provenance et l’intégrité d’une information. Voici quelques exemples parmi tant d’autres : Données militaires, contrats d’affaires, actes authentiques (notaire, avocat)…

Continuer la lecture de « Déployer une PKI: Pourquoi et comment (1ère partie) »

L’utilité réelle de l’objectif de sprint et comment le mettre en œuvre

Dans cet article, nous allons aborder l’importance de l’objectif de sprint, ses liens avec les cérémonies Scrum, comment le définir et comment l’utiliser.

sprint goal archery target

Pizzapido…

Arthur est Product Owner de Pizzapido, une application qui permet de commander une pizza fraîchement cuite pour la retirer dans un automate. Avec son équipe ils terminent le sprint 14 qui met un gros focus sur la redéfinition de l’expérience utilisateur de création de compte. En effet, il s’est rendu compte que certains utilisateurs ne parviennent pas au bout du processus de création de compte et que cela fait donc une perte potentielle de commandes et donc de revenus. Il a donc inclus dans le sprint 14 plusieurs User Stories pour améliorer cette partie de Pizzapido.

Continuer la lecture de « L’utilité réelle de l’objectif de sprint et comment le mettre en œuvre »

Burndown chart Scrum: A quoi ressemble le votre?

Burndown chart Scrum

Pour les équipes Scrum, le Burndown chart (graphique) est un outil de mesure visuel qui montre le travail restant à faire par rapport au taux d’achèvement prévu. Son objectif est de permettre au projet d’être sur la bonne voie pour fournir l’incrément attendu à la fin du sprint.

Le taux de progression d’une équipe Scrum s’appelle « vélocité ». Il exprime la quantité de story points complétés par itération. Une règle pour calculer la vélocité est que seuls les stories « finies » à la fin du sprint sont comptés. On ne comptera donc pas les travaux partiellement terminés (par exemple: codage terminé mais test manquant).

Continuer la lecture de « Burndown chart Scrum: A quoi ressemble le votre? »