Archive for the ‘authentification’ Category

Entité multi-rôles – suite

Lundi, mai 22nd, 2017

Suite de l’article sur les Entité multi-rôles.

La gestion de multiples clés cryptographiques asymétriques dépendantes d’une seule clé principale impose des contraintes lors de la synchronisation d’entité mais il n’est pas difficile à mettre en place.

La première idée serait de protéger les mots de passe des clés secondaires avec la clé primaire. Mais cette clé primaire a avant tout le rôle d’authentification, elle ne doit donc pas servir à faire du chiffrement.

La seconde idée consiste à dériver (PBKDF) les mots de passe des clé secondaires du mot de passe de déverrouillage de la clé primaire. Ainsi la clé primaire ne sert qu’à l’authentification. Cela implique aussi que la modification du mot de passe de la clé primaire force le changement de mot de passe de toutes les clés secondaires associées.

La dérivation des mots de passe peut prendre en compte la partie publique de la clé primaire et de la clé secondaire concernée. Elle peut aussi prendre en compte, en plus, l’ID dans nebule du rôle associé. Une implémentation complète devra être proposée.

Entité multi-rôles

Jeudi, avril 20th, 2017

D’un point de vue robustesse et sécurisation des clés cryptographiques, il est recommandé de séparer les rôles des différentes clés utilisées. Une clé crypto ne doit avoir qu’un seul usage, c’est à dire un seul rôle. Dans l’implémentation des entités dans nebule, les entités étant des clés cryptographiques avec de multiples rôles, il va falloir les scinder.

Les rôles les plus fréquents sont :

  1. L’authentification. C’est utilisé pour le déverrouillage des entités.
  2. La signature. Tous les liens sont signés.
  3. Le chiffrement. Il intervient dans la protection des objets et la dissimulation des liens.

Toutes les clés liées à des rôles peuvent être rattachées à une clé cryptographique asymétrique principale et reliées à celle-ci par des liens. Il est possible par la suite d’étendre sans problème les rôles comme par exemple les rôles d’autorités locales.

La segmentation des clés par rôles impose la gestion de multiples clés pour une entité, notamment lors de la synchronisation sur différents supports. Mais elle permet en cas de compromission d’une clé de limiter l’étendu des dégâts.

Sondages et votes

Vendredi, septembre 11th, 2015

Dans un article La Suisse pourrait imposer l’open-source pour le vote électronique de Numerama, il est de nouveau question de la mise à disposition du code source du programme sous forme de logiciel libre.

L’avenir du vote électronique ne fait aucun doute, seule sa réalisation pose problème aujourd’hui. Beaucoup de débats comparatifs et contradictoires ont lieux vis-à-vis de la pertinence du vote électronique et de la confiance que l’on peut apporter aux machines de vote et au processus dans son ensemble. Ces débats peuvent paraître très conservateurs mais ils sont néanmoins nécessaires puisque le vote est un acte fondamental de nos démocraties, c’est le moyen d’expression de chacun d’entre nous.

La confiance en ce genre de machine de vote et du code qui l’anime ne peut être assurée sans l’ouverture du code à minima en lecture. Il faut aussi connaître précisément l’environnement de compilation et d’exécution pour le code soit parfaitement reproductible. Et bien sûr, il faut être sûr ce c’est bien ce code qui a été utilisé et pas un autre.
Invoquer le secret industriel sur du code pour un processus parfaitement connu et un enjeu majeur de démocratie, c’est particulièrement malhonnête. Tout au plus une société éditrice peut-elle demander un droit de paternité et une restriction de commercialisation à son seul bénéfice. Mais il suffit à l’état qui fait la commande du code de demander, et payer, explicitement la libre diffusion ou la libéralisation complète du code.

Le code doit être capable dans son ensemble de permettre la centralisation des votes, l’anonymisation des électeurs ainsi que la vérification en temps réel et à postériori du décompte des votes. L’authentification de l’utilisateur devrait être le principal problème mais il apparaît que c’est en fait le décompte et sa vérification qui interpellent le plus souvent les détracteurs du vote électronique.

Un vote a un point de départ dans le temps et une fin à partir de laquelle le décompte des votes est considéré comme définitif.

L’anonymisation est aussi un problème pour la vérification de conformité du vote à postériori puisqu’elle casse le lien sûr entre le votant et le vote unitaire. On peut ainsi affirmer que le votant à voté (il a posé un papier et signé le paraphore) mais on ne peut pas le prouver à postériori (était-ce vraiment lui).
La capacité de multi-entité et la dissimulation de liens dans nebule permettent de résoudre ce problème.

Voici un scénario possible de vote avec les objets et liens de nebule :

  1. Pour un vote, une entité maîtresse du vote est générée. Elle est explicitement reconnue par les autorités comme telle. Son seul rôle est de générer les jetons de vote et de les attribuer aux électeurs.
  2. L’entité maîtresse du vote va générer autant d’objets jetons qu’il y a de votants. Ces jetons sont aléatoires et n’ont pas de relation directes avec les électeurs. Chaque jeton est en fait la partie publique d’un bi-clé cryptographique (RSA par exemple). La clé privée de chaque jetons est protégé par un mot de passe stocké dans un objet protégé par et pour l’entité maîtresse (dans un premier temps).
  3. Le jeton est en fait l’entité qui réalisera le vote via la clé privée. Chaque vote peut être vérifié par rapport au jeton, c’est à dire la clé publique.
  4. Pour chaque objets de clés privées de chaque jetons, l’entité maîtresse va partager le secret de chiffrement de l’objet contenant le mot de passe. Le lien entre objet chiffré et objet non chiffré est dissimulé, c’est à dire que c’est un lien de type c masquant le vrai lien.
  5. La clé privée de l’entité maîtresse est détruite. Il n’est ainsi plus possible de retrouver l’intégralité des relations en les jetons et les électeurs mais il est possible de vérifier que tous les électeurs ont reçus un lien dissimulé et de vérifier tous les jetons réalisant le vote.
  6. Pour un vote, une entité de décompte du vote est générée. Elle est explicitement reconnue par l’entité maîtresse Son seul rôle est de recueillir et de valider les votes. La période de vote démarre.
  7. L’électeur, c’est à dire l’entités votantes, va récupérer auprès de l’entité maîtresse du vote l’intégralité des jetons et des clés privées associées (et pas juste son jeton). Il va ainsi obtenir tous les liens dont le lien dissimulé le concernant. Via le lien dissimulé, il va savoir quel est la clé privée du jeton que l’entité maîtresse lui a attribué. Disposant de cette information il peut déprotéger à son profit l’objet contenant le mot de passe de la clé privée du jeton.
  8. L’électeur, mettant à profit la clé privée du jeton, peut réaliser un ou plusieurs votes, seul le dernier est pris en compte. Le vote consiste en un lien entre le jeton et le choix de vote dans le contexte de l’entité de décompte du vote (champs méta).
  9. L’entité de décompte du vote vérifie régulièrement auprès de tous les électeurs la présence de liens dont elle est le contexte. au fur et à mesure de la récupération des liens, elle se les approprie (signature du lien de vote).
  10. A la fin de la période de vote, la clé privé de l’entité de décompte du vote est détruite. Plus aucun vote ne peut être ajouté, modifié ou supprimé. Les votes comptabilisés sont ceux qui ont été signés par l’entité de décompte du vote.
  11. L’électeur qui souhaite rendre publique son vote a juste à prouver qu’il dispose du jeton en utilisant sa clé privée pour autre chose que le vote en relation avec sa véritable entité. Il peut aussi révéler le lien dissimulé que lui avait généré l’entité maîtresse du vote.

Un des aspects des liens dissimulés est qu’il est possible de les dissimuler pour plusieurs entités. Ainsi il est possible de générer une entité d’audit du vote à qui l’entité maîtresse partagera les liens dissimulés, de façon également dissimulé.L’entité d’audit devient capable à postériori de vérifier la bonne association entre jetons de vote et électeurs sans être elle-même capable d’émettre de nouveaux jetons.

Le sondage est moins contraignant et surtout peut être à choix multiples.

Cosignature

Samedi, mai 9th, 2015

Une réflexion depuis quelques temps porte sur la cosignature (cf Les entités et le code / Redéfinition de puppetmaster). Et elle est toujours d’actualité. Le but est de permettre d’avoir une entité unique mais dont la clé privée soit répartie en plusieurs morceaux, chaque morceau sous la responsabilité d’une personne différente. On doit avoir plusieurs entités qui peuvent communément, et non individuellement, signer pour l’entité unique.

Le problème peux être résolu en ayant un mécanisme qui valide la signature de l’entité unique par la présence d’un nombre pré-définit de signatures d’entités pré-validées. On n’a plus dans ce cas une entité mais un groupe d’entités dont la cosignature est reconnue comme signature du groupe. Dans ce cas, la notion d’entité s’étend et ne sous-entend plus seulement un objet avec une clé cryptographique mais un objet qui constitue un groupe d’entités avec des règles de fonctionnement.

Jusqu’ici, je n’ai trouvé que des solutions matériels avec un seul bi-clé cryptographique conservé dans une puce et dont l’usage est contraint par l’authentification de plusieurs personnes physiques. Ce n’est pas satisfaisant puisque toutes les personnes doivent être présentes au même endroit au même moment pour activer la clé privée. Les solutions de cosignatures que j’ai trouvé se contentent de gérer de multiples signatures d’un document mais sans gérer cette notion de communauté.

Authentification et mot de passe

Samedi, février 14th, 2015

Dans la version précédente, procédurale, de la librairie nebule en php, l’authentification était gérée via des variables de la session. On retrouvait l’ID de l’entité en cours ainsi que l’ID de la clé privée associée et le mot de passe (si déverrouillé) de cette clé privée.

Les anciennes variables :
$_SESSION['nebule_publ_entite']
$_SESSION['nebule_priv_entite']
$_SESSION['nebule_pass_entite']

Dans la nouvelle version de la librairie, en programmation orientée objet, la première variable qui référence l’entité en cours d’utilisation est toujours nécessaire.
Par contre, la variable qui référence la clé privée est encore utilisé mais n’est déjà plus vraiment indispensable puisque l’instance (l’objet au sens programmation) de l’entité contient la référence à l’ID de sa clé privée. Cet ID de clé privée est pré-calculée lors de l’initialisation de l’instance et est accessible par une fonction publique. Il est même possible que cette variable de session pour la clé privée disparaisse à terme faute d’usage.
Enfin, la variable contenant le mot de passe de la clé privée, elle, disparaît définitivement. Elle n’était renseignées que lorsque l’entité était déverrouillées. Désormès, le mot de passe, lorsque fourni, est stocké dans l’instance de l’entité en cours. Cette instance référence ainsi la clé privée et le mot de passe associé. Ce mot de passe est bien sûr vérifié lors de son enregistrement puisque c’est la seule et unique condition pour considérer l’entité comme déverrouillée, que le mot de passe soit valide sur la clé privée.

En terme de sécurité du code, c’est plus propre. Le mot de passe ne peut être consulté directement par un module malveillant comme avec une variable de session par essence globale et donc accessible partout. Cependant, le mécanisme n’est pas parfait puisqu’une lecture brute de l’instance permet d’en extraire le contenu… et donc le mot de passe. Il faudra trouver un mécanisme pour renforcer ça…
L’usage d’un sel pour le mot de passe est en cours de réflexion sachant qu’il faudra dans ce cas créer un lien pour le rendre publique. C’est un renforcement de la sécurité du mot de passe mais potentiellement une source de panne.

En terme de gestion des entités, c’est plus facile si on change vers une entité que l’on maîtrise puisque les mots de passe des entités esclaves sont accessibles et peuvent être pré-injectés dans les entités correspondantes. Et puis en cas de bascule vers une de ces entités esclaves, le retour à l’entité maîtresse est plus facile aussi puisque le mot de passe pourra rester dans celle-ci.

En terme d’évolution, il est déjà prévisible qu’une forme avancée d’un usage multi-entité verra le jour. CF Entités multiples. La pré-initialisation des mots de passes de toutes les entités sous contrôle (entités esclaves) rendra cet usage beaucoup plus facile. Pour rappel, cet usage multi-entité permettra au choix soit d’utiliser une et une seule entité à un instant donné mais de pouvoir immédiatement et facilement changer d’entité, soit d’utiliser simultanément tout ou partie des entités sous contrôle. Dans ce dernier cas, les actions seront par contre faites avec une seule entité pré-definie pour cela.

Voici la structure de la classe Entity :

class Entity extends Object
{
	const ENTITY_MAX_SIZE = 16000;
	const ENTITY_PASSWORD_SALT_SIZE = 128;
	const ENTITY_TYPE = 'application/x-pem-file';

	private $_publicKey = '';
	private $_privateKeyID;
	private $_privateKey = '';
	private $_privateKeyPassword;
	private $_privateKeyPasswordSalt;
	private $_issetPrivateKeyPassword = false;
	private $_faceCache = array();

	public function __construct(nebule $nebuleInstance, $id);
	public function __destruct();
	public function __toString();
	private function _loadEntity($id);
	private function _createNewEntity();
	private function _verifyEntity($entity);
	public function getType();
	public function getKeyType();
	public function getPublicKeyID();
	public function getPublicKey();
	private function _findPublicKey();
	public function getPrivateKeyID();
	private function _findPrivateKeyID();
	private function _findPrivateKey();
	public function setPrivateKeyPassword($passwd);
	public function unsetPrivateKeyPassword();
	public function checkPrivateKeyPassword();
	public function changePrivateKeyPassword($newpasswd);
	public function getFullName();
	public function getLocalisations();
	public function getLocalisation();
	public function getFaceID($size=400);
}

Partage simplifié d’une entité

Jeudi, juillet 24th, 2014

Pour l’utilisateur d’un logiciel de communication, mémoriser un mot de passe complexe est une tâche ardue, voir sans intérêt.

Le problème est le même avec les pages web, leurs noms doivent être facile à retenir et à retaper sans faute. Et il en est ainsi pour les correspondants dont il faut se souvenir au pire de leurs adresses emails ou au mieux de leurs noms ou pseudonymes. Dans certains cas, il faut se souvenir du pseudonyme et du site web sur lequel on peut trouver un correspondant.
Le projet nebule vise notamment à fédérer des identités en même temps que les données. Mais cela entraîne inévitablement l’utilisation d’identifiants globalement uniques, donc longs.
Certains projets comme minilock visent à essayer de réduire ces identifiants avec des encodages comme le Base58.

On peut aussi utiliser uniquement une localisation, c’est à dire adresse de type http ou email. Ainsi, pour une adresse http, il faut héberger à une adresse précise une entité par défaut. Si un hébergeur veut gérer plusieurs entités, il ne pourra pas les garder facilement dans le même espace, le même nom de domaine, mais il devra au contraire les séparer dans des espaces différents. Mais est-ce vraiment la solution ?

Dans l’article sur le Détournement de liens de mise à jour (CF blog sylabe), on a vu qu’il était possible de créer une sorte de pseudonyme d’entité nebule. C’est un détournement du lien de mise à jour depuis un objet fictif vers, dans notre cas ici, une entité définie. Prenons comme exemple un prénom Fabio auquel correspondrait un objet fictif fab10. Ainsi, sur une instance de nebule, cet objet reverrait systématiquement vers l’entité de l’utilisateur. Ça résout le problème localement.

Cependant, on peut facilement imaginer que tous les utilisateurs qui ont se prénom vont avoir des prétentions sur cet objet fictif. Comment va se résoudre le conflit ?
Assez mal en fait. Si on a des amis en commun, on devrait rapidement retrouver le bon identifiant de l’entité. Mais ça se corse si on a deux entités avec des prétentions sur ce pseudo dans nos entité proches. Dans ce cas, c’est le calcul social qui va déterminer l’entité qui pourra hériter du pseudo, et cela fait une chance sur deux de ne pas tomber sur la bonne entité…
En plus, on peut imaginer aussi que dans une situation de harcèlement ou de dénigrement, des entités agressives essayent aussi de s’approprier le pseudo. Cela pourrait rendre le pseudonyme difficile à utiliser puisqu’il ne renverrait que rarement à la bonne entité.

Cette méthode est donc loin d’être parfaite. Elle peut être raisonnablement utilisée soit dans un petit groupe d’utilisateurs soit si elle est associée à une localisation http, email, etc…

Renouveler son entité

Dimanche, décembre 8th, 2013

Pour l’instant, les entités sont figées. Mais il faudra prévoir de changer leurs mots de passes et de les migrer vers de nouvelles entités au besoin.

Le changement de mot de passe nécessite de régénérer l’objet de clé privé qui change. Il faut évidemment préalablement déverrouiller l’entité, donc sa clé privée. Une fois le mot de passe changé, il faut lier la nouvelle clé privée à la clé publique puis supprimer le lien de l’ancienne clé privé. Il faut marquer à supprimer l’objet de l’ancienne clé privée.

Dans le cas d’une migration d’entité, c’est un peu plus complexe. Ce besoin répondra souvent suite à un problème de compromission ou de corruption d’entité.
Il faut générer une nouvelle entité autonome. Faire un lien de mise à jour de l’ancienne entité vers la nouvelle. Dans la mesure du possible, ce lien de mise à jour doit être signé à la fois par l’ancienne et la nouvelle entité. Puis l’objet de la clé privée de l’ancienne entité doit être marqué à supprimer à la fois par l’ancienne et la nouvelle entité.
Si l’entité avait été corrompue, c’est à dire qu’il était impossible de la déverrouiller, c’est un vrai problème. Dans ce cas, les liens de mise à jour d’entité et de suppression de clé privée ne pourront être signés par l’ancienne entité. rien ne permet de distinguer une opération légitime suite à un problème d’une tentative de détournement par une autre entité. Il peut tout au plus être possible de regarder si l’entité génère de l’activité, donc qu’elle n’est pas corrompue.
En cas de compromission de l’entité, on peut faire une mise à jour vers une nouvelle entité. Mais celui qui a volé la clé privée de l’entité peut le faire aussi de son côté. Il est difficile dans ce cas de déterminer qui est la véritable nouvelle identité et pas une usurpation… Peut-être le côté sociale, comportemental, d’une entité peut nous aider à posteriori?

Yubikey et la double authentification

Samedi, janvier 26th, 2013

Une des bêtes noires de la sécurité des utilisateurs et de leurs informations sur l’Internet est le mot de passe. Ou plutôt devait-on dire la multitude de mots de passes et de comptes utilisateurs qui vont avec.

Chaque service web nécessite un compte utilisateur pour être utilisé, normal. Ce qui est moins normal, c’est que cette identification reste assez strictement localisée au service en question. A part quelques tentatives qui n’ont remportée qu’un succès d’estime, chaque service gère jalousement ses utilisateurs. Il en résulte un multitude de comptes utilisateurs différents avec potentiellement autant de mots de passes.
La gestion de l’identité sur l’Internet est un vrai problème. La gestion des mots de passes associés encore plus. Même si l’on met le même mots de passe partout, il faut régulièrement le retaper. Et bien sûr, avec un mot de passe unique, on devient vulnérable au premier service qui ne sécuriserait pas correctement ceux-ci.

Yubico propose une solution basé sur le mot de passe à usage unique (OTP – One Time Password). L’ensemble fonctionne sur le principe de ‘ce que je connais‘ et ‘ce que j’ai‘. La double authentification repose donc sur deux moyens combinés de prouver son identité. On doit fournir les deux ou prouver que l’on détient les deux.

  1. Ce que je connais‘, c’est typiquement un nom d’utilisateur et un mot de passe.
  2. Ce que j’ai‘, c’est un objet dont je dispose. Cet objet doit être capable de prouver sa présence de façon numérique. C’est ici la YubiKey.
  3. Ce que je suis‘, c’est le plus dur à obtenir… puisque c’est généralement ce que l’on cherche.

La clé YubiKey branchée en USB émule un clavier et envoie un mot de passe OTP lorsque l’on appuie sur un bouton de la clé. Ce mot de passe unique est dérivé de l’identifiant de la clé, d’un numéro de séquence, d’une empreinte CRC et de divers autres champs. Le tout est converti en caractères imprimables et envoyé comme si il était tapé sur un clavier.
Ce OTP est transmis au serveur en même temps que le nom d’utilisateur et éventuellement un autre mot de passe (double authentification). Le serveur le transmet au YubiCloud pour vérification et attend une réponse positive ou négative sur la validité de l’OTP pour donner l’accès au service à l’utilisateur… ou pas.
L’OTP change à chaque fois et ne peut être rejoué. Il peut donc être divulgué une fois utilisé.
La YubiKey peut être volée, sans le compte à utiliser (ou le deuxième mot de passe) elle est inutilisable.
Si double authentification, le mot de passe peut être volé (keylogger), il n’est pas utilisable sans la YubiKey à côté.

Une des propriétés intéressante de cet implémentation, c’est que l’on peut voir l’ensemble comme la transmission de messages chiffrés (symétrique) entre la YubiKey et la YubiHSM. Toutes les clés connaissent l’unique (ou pas loin) mot de passe secret de chiffrement. On fait confiance au matériel (les clés USB) pour savoir garder le secret.

Le système est de loin préférable à la simple authentification par mot de passe. Mais il n’en présente pas moins des problèmes :

  1. Une petite polémique est apparue sur la robustesse réelle du système. Un CRC16 permet de vérifier la validé du paquet. Ce CRC est inclus dans les données chiffrées et couvre donc 128-16=112bits. En jouant des paquets au hasard, il y a 1/(2*2^16) chances que la signature du CRC16 soit cohérente avec le reste. Si l’on compte qu’il faut statistiquement parcourir la moitié des valeurs pour en trouver une bonne, cela donne une probabilité de 1/(2^16). Cependant, dans les données chiffrées, il y a aussi le champ private identity de 6 bytes=48bits. Ce champs étant vérifié comme nul ou valide par les serveurs, la probabilité remonte à 2*1/(2^(16+48)) soit 1/(2^63). Ce qui sauve les meubles c’est que l’attaque doit passer par le réseau, la solidité réelle de l’ensemble est de 2^63 et non de 2^128…
  2. Il faut la coopération active des services qui authentifient les utilisateurs. La méthode d’authentification doit être modifiée pour supporter la vérification de l’OTP en liaison avec le YubiCloud, l’infrastructure qui valide réellement l’authentification. Pour les personnes qui gèrent elles-même leurs blogs ou autres services, c’est un réel gain. Mais pour un gros acteur de l’Internet c’est plutôt une ingérence sur un sujet sensible que sont les utilisateurs et tout ce qu’ils rapportent. Cela à donc autant de chance d’être adopté que d’autres solutions par le passé comme OpenID, faible.
  3. La solution nécessite une connectivité vers l’Internet et le YubiCloud pour valider l’authentification. Impossible donc de travailler hors-ligne. Il y a 5 serveurs dans le monde, c’est déjà pas mal mais c’est aussi encore trop peu pour résister à un DDOS ciblé. Et en cas d’absence de connexion prolongée aux serveur, tous les services associés sont eux-aussi paralysés. On a un point de défaut unique.
  4. Comment va se comporter l’ensemble lorsque le compteur anti-rejeu va boucler ? La clé ne marchera plus. La taille du compteur est de 15bits=32768 utilisations (avec branchement de la clé).
  5. Volontairement, la YubiKey ne peut être mise à jour. La clé est accessible en lecture seule, ce qui empêche la diffusion de virus et réduit la surface d’attaque de celle-ci. Mais que se passera-t-il quand, inévitablement, une faille sera trouvée sur cette clé ? Poubelle.

D’autres questions restent en suspend. L’analyse rapide de la documentation sur le site web de Yubico ne permet pas d’y répondre.

  1. Clé unique de chiffrement AES entre toutes les clés YubiHSM ? Ou une clé AES par YubiHSM ? Ce système de clés secrètes interdit notamment toute concurrence avec les mêmes clés. Utiliser la cryptographie asymétrique plutôt que symétrique aurait permit bien plus de choses et relevé la sécurité à plus long terme.
  2. Et si un serveur d’authentification du YubiCloud répond toujours OK même si les OTP sont invalides ? Quelle est la robustesse de l’infrastructure du YubiCloud ? La liaison entre les API côté clients et les serveurs API Validation Servers est chiffrée avec une clé partagée. Les serveurs KSM avec leurs YubiHSM sont indépendants des API Validation Servers. Mais si la clé AES semble bien protégée dans les YubiHSM, je n’ai pas vu de mécanisme de signature de la réponse.
  3. Yubico ne semble pas aimer la cryptographie symétrique, elle n’est employée nulle part. Dans un contexte entièrement centralisé autour de quelques serveurs, la cryptographie symétrique appliquée à tous les échanges reste cependant acceptable. Mais on en revient à une critique précédente, cela renforce l’unicité du point de défaillance de ces serveurs.

Qu’en penser ?
Toute la sécurité repose sur la/les clés AES des YubiHSM, la robustesse de la clé YubiKey et sur l’implémentation du chiffrement de l’OTP. La solution semble viable à court terme. Trop de défauts la condamne malheureusement à long terme.
Bref, c’est mieux que de se reposer uniquement sur le user/password, mais il faudra l’abandonner sans regrets au premier signe de faiblesse.

Liens :
http://www.yubico.com/
http://www.wired.com/wiredenterprise/2013/01/google-password/all/
http://www.yubico.com/products/yubikey-hardware/
– http://static.yubico.com/var/uploads/pdfs/YubiKey_manual-2.0.pdf
http://www.yubico.com/wp-content/uploads/2012/10/YubiCloud-OTP-Validation-Service-v1.1.pdf
http://www.schneier.com/blog/archives/2013/01/googles_authent.html
http://gonzague.me/yubico-yubikey#axzz2IzWaf5Dr
https://bitcointalk.org/index.php?topic=85648.msg943612#msg943612
http://openid.net/

Identification/authentification sur l’internet des objets

Mardi, décembre 4th, 2012

Un interview de R.Haladjian revient sur l’Internet des objets.

L’internet des objets, c’est en gros la capacité d’interagir à distance avec des objets de notre environnement, et à ces objets de communiquer sur le réseau de façon autonome.

Une des remarques concerne la connectivité en IPv6. Ils sont revenus à IPv4 parce que « par exemple une prise électrique disposait d’un serveur et n’importe qui ayant obtenu l’adresse de cette prise électrique pouvait la pinger pour l’allumer et l’éteindre à distance. Il fallait donc mettre un pare-feu pour empêcher l’accès… Donc finalement il est plus intéressant de rester en IPV4 avec un DHCP qui distribue des adresses« .
Il est étonnant que l’on revienne à une solution dont on sait pertinemment qu’elle ne supportera pas la mise à l’échelle (de l’internet, et donc du monde) des objets connectés sur le réseau (internet). On se contente d’une vision de ces objets à courte distance, en gros de l’ordre de grandeur de la maison.
Ce recul est je pense une mauvaise réponse à un problème mal posé. Le problème concerne l’identification de qui peut dans l’exemple allumer/éteindre la lampe. Si il n’y a pas d’identification, c’est normal que tout le monde puisse le faire, une adresse IP n’est pas à considérer comme un secret même en IPv6. Mais mettre en place une identification/authentification forte sur les méthodes actuelles est fastidieux pour un grand nombre d’objets. Le problème est d’ailleurs déjà un problème commun sur les ordinateurs résidentiels. Donc parce que l’on ne sait pas mettre en place une identification correcte, on bride l’ensemble du système.
Je n’ai pas regardé comment est faite l’identification/authentification sur leurs objets. Mais cette remarque m’incite à penser qu’elle n’est pas innovante, et donc pas à la hauteur. Et, en regardant du côté de nebule, le problème semble du coup beaucoup plus facile à résoudre…

Il y a un autre aspect de l’internet des objets, c’est la gestion des objets physiques inertes d’un point de vue numérique. Ils sont reconnus par un identifiant unique, mais ils n’interagissent pas. C’est l’exemple du code barre sur les articles à vendre d’un magasin, ou la puce RFID qui les remplacera, ou la plaque d’immatriculation d’une voiture. La vision primaire de l’internet des objets avec des étiquettes collées partout me semble ubuesque : le monde deviendrait une poubelle recouverte d’étiquettes en tout genre que plus personne ne regarderait…
Pour nebule, ces identifiants numériques, quel qu’en soit leur forme ou norme, sont encodés dans des objets avant de pouvoir être liés et donc gérés. On peut même penser qu’ils seront attaché virtuellement à des positions géographiques.

Liens :
http://mobile.clubic.com/technologies-d-avenir/actualite-528965-leweb-12-haladjian-pere-nabaztag-internet-objets.html
http://fr.wikipedia.org/wiki/Internet_des_objets
http://fr.wikipedia.org/wiki/Web_3.0

L’internet des objets et les objets de l’internet

Jeudi, novembre 29th, 2012

Les objets physiques qui peuplent notre environnement habituel ont une caractéristique particulière, ils sont uniques. On peut certes faire une copie, voire reproduire un objet en plusieurs millions d’exemplaires, chaque objet restera unique avec sa matière propre et ses défauts propres. Chaque objet peut être ainsi assemblé, remodelé ou refondu dans un autre objet, cela n’a aucun impact sur ses congénères.

Et les objets du monde numérique?
Ceux-ci ont l’équivalent d’une forme propre comme un objet physique. On peut distinguer un objet numérique d’un autre par cette forme que l’on appellera plutôt empreinte, mais aussi par sa localisation. La localisation est souvent représenté par un identifiant dans une arborescence ou sur un réseau, c’est un classement humanisé et peu fiable. Ainsi cette dualité de l’objet dans l’espace numérique a une conséquence importante immédiate, le même objet exactement peut exister simultanément en plusieurs endroits. Il faut donc considérer que chaque emplacement de l’objet reçoit une copie exacte de l’objet, c’est à dire sans altération, sinon cela devient un autre objet.

(suite…)

Réflexion – stabilité de l’identifiant

Dimanche, février 13th, 2011

Je bouquine un livre en ce moment :
« Gestion des identités » de OCTO Technology, ISBN:978-2-9525895-1-2, avril 2007, www.octo.com

Au cours du développement de l’Identifiant Unique Personnel (IUP), il est noté que trois contraintes doivent absolument être respectées.
L’IUP doit être :

  1. unique (strictement lié à une personne) ;
  2. inaliénable (ne peut être réattribué à une autre personne) ;
  3. stable (dans le temps).

En référençant un utilisateur (une entité) par un bi-clé cryptographique, respecte-t-on ces contraintes?

(suite…)

Nouvelle clé GPG…

Mercredi, octobre 27th, 2010

Il fut un temps… le bon vieux temps comme ils disent… où j’utilisais PGP v2.6.3i (sous M$ Windows, la loose) notamment avec la messagerie… (suite…)

Monkeysphere

Jeudi, octobre 7th, 2010

Le projet Monkeysphere [2] vise à étendre l’utilisation de OpenPGP [7] ou GnuPG [8] à l’authentification sur SSH [5] ou SSL [3]. Il est présenté brièvement en [1].

(suite…)