Site personnel de Jean GEBAROWSKI sur la sécurité des systèmes informatiques
Archives de catégorie : Concepts
La catégorie concepts regroupe les généralités utiles en sécurité des SI et parfois d’autres plus globales à l’informatique, mais ayant un sens ou un intérêt particuliers en SSI.
On peut traduire par tas de données, même s’il n’y a pas l’analogie aquatique. Quoi que tas de données serait mieux approprié pour big data. Parce que lac de données c’est bôf. Bref. Si j’ai bien compris1 dans ce monde merveilleux de la grosse donnée, un datalake est un entrepôt de données, mais dont la grande force est de n’avoir aucun format et de stocker des données quasi-brutes (en les améliorant je pense de quelques métadonnées, à savoir d’où viennent ces données, qui les a produites, quand, etc.).
Avant, on récupérait des données, on les formatait pour les stocker de façon structurée quelque part, ça s’appelait un datawarehouse. Et après on chargeait ce dont on a besoin (Extract – Transform – Load).
Maintenant c’est mieux : on les stocke en tas de merde données, sans modification ni altération donc sans perte d’info (ce qui est bien, faut reconnaître), puis on les charge, et seulement à la fin on en fait quelque chose, en leur appliquant des filtres, des modèles, des structures, mais a posteriori2. Donc on passe en Extract – Load – Transform. Comme les puissances de calcul et de stockage peuvent maintenant le permettre (c’est-à-dire stocker des données en tas de merde sans pour autant que ça soit trop le bordel bazar), ben on le fait.
Et on vient de révolutionner pour la 256e fois l’informatique.
Les fonctions de hachage sont des fonctions particulières très utilisées dans le cadre de la sécurité informatique, notamment dans le domaine de la cryptographie et des certificats numériques. Elles permettent d’obtenir une empreinte, également appelée condensat (« hash »), à partir d’un message ou de tout document numérique.
Il existe un nombre assez restreint de fonctions de hachage, car elles sont assez complexes à mettre au point et reposent sur des mécanismes mathématiques complexes.
Principales caractéristiques
En pratique
Une fonction de hachage est une fonction mathématique particulière permettant de calculer rapidement l’empreinte d’une donnée informatique. Une fonction de hachage doit présenter les caractéristiques suivantes :
La taille du condensat (« hash ») est fixe (pour un algorithme donné) ;
Elle ne fonctionne que dans un sens (c’est-à-dire qu’il n’existe pas de fonction inverse) ;
Pour une entrée donnée, on doit toujours obtenir le même résultat (empreinte) ;
Toute modification même très légère en entrée produit un résultat très différent ;
Elle est rapide à calculer.
L’intérêt de ce condensat est d’avoir une sorte de signature d’un document :
L’irréversibilité permet de ne pas pouvoir retrouver le document original à partir du condensat (il est même très difficile de construire un document quelconque à partir d’une empreinte donnée) ;
Si deux hashs sont différents, alors les documents initiaux sont forcément différents.
Intérêt et usage des fonctions de hash
L’intérêt principal est de permettre d’identifier la donnée de façon presque sûre sans pour autant transmettre la donnée : il est mathématiquement très difficile (voire impossible) de retrouver la donnée initiale à partir de son empreinte.
Principe d’une fonction de hachage. Une donnée identique en entrée donnera la même empreinte. A l’inverse, une légère différence donnera une empreinte complètement différente.
Ces fonctions peuvent avoir plusieurs usages, plus ou moins critiques. Cela peut aller du simple contrôle technique pour s’assurer qu’un message a été correctement transmis (ou n’a pas été modifié), jusqu’à la signature électronique.
Pour le mot de passe
On s’en sert également pour chiffrer les mots de passe dans beaucoup de systèmes. Puisque ces fonctions sont rapides, on peut facilement calculer l’empreinte d’un mot de passe ; c’est alors lui qui est stocké dans le système, et non le mot de passe en clair. Comme il est difficile de retrouver la donnée initiale à partir d’une empreinte, la protection ainsi obtenue est bonne (plus ou moins en fonction de l’algorithme utilisé et de sa mise-en-oeuvre).
Lorsqu’un utilisateur veut se connecter à un système, il entre son mot de passe. On calcule ensuite son empreinte : si c’est la même que celle stockée dans le système, l’accès est alors autorisé.
Pour vérifier l’intégrité d’une donnée
Si on souhaite vérifier qu’une donnée (un fichier informatique) est intègre, c’est-à-dire non modifiée, on communique le fichier au destinataire et ce dernier recalcule lui-même son empreinte : celle-ci doit correspondre à une empreinte de référence.
Les fonctions de hachage permettent le contrôle d’intégrité et la prise d’empreinte numérique.
Toute la subtilité vient ensuite de la façon dont on connaît cette empreinte de référence : quand on télécharge un fichier, cela peut être une somme de contrôle ; pour un certificat, c’est une des données du certificat.
Pourquoi presque sûre ?
L’empreinte est généralement de petite taille et de longueur fixe. Même si cela représente beaucoup de possibilités, ce nombre est fini, alors que le nombre d’entrées possibles est, lui, infini.
Statistiquement, il est donc très peu probable que deux données différentes en entrée produisent la même empreinte, mais c’est possible : la difficulté augmente avec la longueur choisie pour l’empreinte. Pour SHA-1, c’est 160 bits. pour SHA-256 c’est… 256 bits !
Trouver deux données différentes ayant un même hash est appelé collision. La probabilité d’une collision dépend principalement de la longueur du hash, mais aussi (un peu) de la façon dont il est calculé (notamment la rapidité de son calcul).
Les propriétés et les attaques
Propriétés formelles attendues d’une fonction de hachage
Reprenons un peu le chemin de la théorie. Selon McAfee Labs (Intel)1, une bonne fonction de hachage doit avoir les propriétés suivantes :
Résistance à la préimage : Pour une valeur de hachage donnée, il doit être difficile de trouver un fichier ou message pour lequel la fonction de hachage produirait une valeur identique.
Résistance à la seconde préimage : Pour un fichier ou message donné, il doit être difficile de trouver un second fichier ou message tel que la fonction de hachage produirait la même valeur pour les deux fichiers ou messages.
Résistance à la collision : Il doit être difficile de trouver deux fichiers ou messages distincts pour lesquels la fonction de hachage produirait la même valeur de hachage.
Dis comme ça, il n’est pas évident de voir la différence (je parle pour moi). Mais l’enjeu de cette formalisation est de voir quels sont les types d’attaques possibles : chaque propriété est plus ou moins forte, pour un type de hash donné. Et plus la propriété est faible, plus une attaque est probable.
Les différents type d’attaques
Attaques par collision
Il existe deux types principaux d’attaques de collisions :
l’attaque de collisions classique : cette attaque consiste à trouver deux messages m1 et m2 différents, tels que hachage (m1) = hachage (m2) ;
l’attaque de collisions avec préfixes choisis : étant donné deux préfixes différents P1 et P2, cette attaque consiste à trouver deux suffixes S1 et S2 tels que hachage (P1 ∥ S1) = hachage ( P2 ∥ S2) (où ∥ est l’opération de concaténation).
Il se passe que la robustesse de SHA-1 est remise en question face au développement de la puissance de calcul disponible. Or SHA-1 est très utilisé, notamment pour les certificats ; or si on peut attaquer SHA-1, on peut alors attaquer des certificats et créer des faux !
La signalétique est généralement univoque. Chrome affiche du vert quand c’est sûr, du gris pour un avis neutre, et du rouge quand le niveau de sécurité est trop faible.
Ce qu’affiche Chrome pour un certificat de type EV considéré comme sûr.
Malheureusement tout le monde applique un peu les règles qu’il veut, comme il le sent, ce qui aboutit à des incohérences pour un utilisateur multi-navigateurs (comme moi). Google a tendance à avoir l’attitude la plus restrictive, ce qui n’est pas forcément condamnable, sauf que cela n’a pas toujours de l’intérêt, comme par exemple sur des sites de peu d’influence ou de peu d’importance.
De plus, Google change ses règle si rapidement qu’un utilisateur peut être perdu en voyant un site « dégradé » (en termes de sécurité) d’une version à l’autre du navigateur.
Exemple d’utilisation
Sous Linux, si vous ne disposez pas des commandes shaxxxsum :
Facile mais instructif : quelques pannes notables sur les grands fournisseurs de Cloud (hors failles de sécurité)
Amazon Web Services
mars 2017 : une panne sur S3 (Virginie) avec plusieurs services affectés 1 . La cause est officiellement… une erreur de frappe2 !
mars 2018 : problèmes réseau (Virgine) 3 , ayant pour origine une panne électrique, avec de forts impacts 4 .
Microsoft Azure
xx
Microsoft Office
xx
IBM
nn
Google Cloud Plateform
17 juillet 2018 : panne sur le StackDriver (données de performance et diagnostic), AppEngine et Cloud Networking touchés5, perturbant notamment Snapchat, Discord, Spotify ou même Pokemon GO 😉
Le calcul multipartite sécurisé est un problème où chacune des parties veut effectuer une opération commune sur des données qui doivent rester privées (aucun des participants ne connaît les données de l’autres) et exactes (non compromises). Il faut aussi qu’un tiers extérieur (attaquant) ne puisse pas accéder lui non plus aux données privées, ni les falsifier.
Participons
Une des applications pratiques est celle du classement de fortunes de millionnaires, sans rendre publics les montants de ces fortunes. Pour deux millionnaires cela revient à savoir lequel est le plus riche sans connaître la fortune de l’autre. La réduction à deux participants n’est pas anodine car elle permet, dans certaines méthodes, une généralisation à plusieurs participants.
Un cas d’usage similaire est celui d’enchères anonymes, ou du comptage des voix dans une élection : il faut savoir qui a gagné sans connaître le vote de chacun (note : ceci est réalisable dans le cas du vote papier, et beaucoup plus difficile dans un vote électronique).
Mathématiquement, cela peut aussi être la création d’un entier aléatoire N que deux parties ne peuvent reconstituer que conjointement. Si N = pq avec p et q étant des facteurs de N, alors aucune des deux parties ne connaît (p,q). Les deux parties peuvent ainsi effectuer des calculs sur des fonctions polynomiales sans révéler les valeurs utilisées en entrée, qui restent donc secrètes, ce qui a des applications en cryptographie.
Les Yao Garbled Circuits sont une solution possible permettant le calcul multipartite sécurisé.
Google Releases Encrypted Multi-Party Computation Tool(June 19, 2019) Google has rolled out its open-source Private Join and Compute (PJC) secure multi-party computation tool. PJC can be used in studies that require data sets containing sensitive information from two separate parties. PJC will allow two sets of data to be used in computations without exposing the data each set contains. The data are encrypted during the computation; all parties can see the result. Read more in: – security.googleblog.com: Helping organizations do more without collecting more data – www.wired.com: Google Turns to Retro Cryptography to Keep Data Sets Private – www.theregister.co.uk: Google takes the PIS out of advertising: New algo securely analyzes shared encrypted data sets without leaking contents – www.zdnet.com: Google open sources Private Join and Compute, a tool for sharing confidential data sets
Le thème n’est pas nouveau, mais entre les progrès techniques (technologiques), l’avènement du big data et autres joyeusetés, nous ne sommes pas près d’avoir la paix quant aux informations personnelles circulant en dehors de notre contrôle. En outre, les petits ruisseaux font les grandes rivières : avec la prolifération des données que nous produisons, il devient possible par inférence ou corrélation de déterminer une quantité énorme d’informations nouvelles et souvent inattendues.
Soyons anonymes
Et bien cela va être de plus en plus difficile. Dernier exemple que je viens de trouver : des chercheurs ont trouvé une technique permettant de déterminer la position d’un téléphone portable à partir d’informations a priorianonymes.
Conservons notre vie privée
Ça va devenir de plus en plus difficile (je me répète). Les applications les plus utilisées sont et seront la cible des autorités et des officines secrètes qui chercheront à savoir tout sur vous, pour des raisons commerciales, idéologiques, de sécurité1, etc.
Le bastionnage (pas sûr que le terme existe) consiste à créer un bastion pour accéder à vos ressources (informatiques). On les utiliser sur des ressources sensibles par leur positionnement (ex : production), par leur nature (ex : outil de gestion de droits), leur contenu, etc.
Ainsi, personne ne peut (en théorie) accéder à vos ressources sans montrer patte blanche et sans passer par ce bastion, qui peut surveiller et mettre en historique les actions effectuées, filtrer les éléments indésirables, gérer des droits d’accès différenciés, etc.
AWS
Création d’un seul VPC ayant 2 sous-réseaux
Un premier subnet « privé » routant tout le trafic de son CIDR en local, tout le reste est dirigé vers une Nat Gateway créée dans le subnet suivant (public) ;
Un second subnet « public » routant tout le trafic de son CIDR en local, tout le reste est dirigé vers une Internet Gateway ;
Enfin une route supplémentaire, associée à aucun des subnets mais directement au VPC, ne route que le trafic local.
Création de 3 Security Groups
Le 1er permet le trafic sortant HTTP/HTTPS (pour permettre le SSH via l’agent SSM), et n’autorise rien en entrée ;
Le 2e permet le trafic entrant sur HTTPS uniquement et autorise tout en sortie ;
Le 3e permet tout le trafic en sortie (sans restriction), ainsi que tout le trafic en entrée mais uniquement quand la source est… lui-même (inutile) ?
La technique de l’authentification basée sur des assertions (ou « claims-based identity ») est un concept extrêmement intéressant sur lequel est basé SAML. Un des principaux attraits de cette technologie est de permettre la fédération d’identité.
Principes
Très concrètement, un système de jetons de sécurité (STS an anglais, pour Security Token Service) permet la gestion de l’identité d’un utilisateur (et de ses droits). Un des grands intérêts de ce concept est de permettre des relations de confiance entre STS, ce qui permet à différents systèmes d’authentification de propager une identité, et donc de créer des fédérations d’identité.
Les briques
Il y a 3 composants dans un tel système :
Le fournisseur d’identité, qui est un STS ;
Un fédérateur d’identité, qui est aussi un STS ;
Une bibliothèque permettant d’utiliser les jetons, au niveau de l’application cible.
Chez Microsoft
Microsoft permet la mise en œuvre d’un tel mécanisme soit dans son propre système d’information, soit dans le cloud.
Attention : L’Active Directory d’Azure est différent de l’Active Directory classique, car ses fonctionnalités sont limitées à celles utiles pour la gestion d’identité. Il n’y a par exemple rien sur la gestion des politiques des postes Windows rattachés, ce qui est une fonctionnalité très importante dans Active Directory.
Dans le cas où on part d’un fournisseur d’identité interne (ex : Windows Server Active Directory with ADFS) pour se connecter à une application externe via Azure Active Directory, on a besoin d’une synchronisation entre le fournisseur d’identité et le fédérateur. ==> A creuser. A contrario, on peut utiliser Azure AD Access Control en tant que fédérateur d’identité, où la synchronisation est inutile, ce qui est beaucoup plus propre.
