Archive for the ‘standardisation’ Category

Marque de temps

Dimanche, mars 30th, 2014

Le marquage du temps tel que réalisé aujourd’hui ne me convient que moyennement. Ce marquage est fait pour chaque lien et permet de leur donner un sens temporel.

La marque de temps est basée sur une norme reconnue : ISO 8601:2004. Elle est forcément absolue. Éventuellement, ce peut être un simple compteur incrémental.
Mais cette norme est loin d’être universelle. Elle se base exclusivement sur un calendrier grégorien. Donc sa référence de temps est biblique, ce qui a une connotation religieuse pour un sujet technique. Passe encore. De par sa référence et sa gestion du temps le plus grand, l’ordre de grandeur du temps géré est de quelques milliers d’années. En gros, on peut indiquer une date entre -9999 et 9999 années.
Certes, cela laisse de la marge dans nos sociétés modernes où on se préoccupe plus de la nano-seconde que du siècle. Mais les Mayas avaient à leur époque, il y quelques temps déjà, un calendrier pour gérer le temps profond. Leur calendrier était à même de donner une date à la création de la terre (si cela a un sens), et sans référence religieuse. Ils ne pouvaient pas par contre gérer finement le temps à petite échelle, en dessous de la journée…

Lorsque l’on aborde le sujet de la gestion du temps avec de multiples références, il faut penser au moyens de synchronisation de ces horodatages. Il faudra pour ça réactiver l’entité kronos

Il n’y a pas 36 solutions pour améliorer le marquage du temps.
On peut ne plus reconnaître de format de temps standardisé… et tenter de déterminer par la forme de la marque de temps la date indiquée dans sa propre référence de temps. Ce travail, fastidieux, peut être facilité par un lien de définition de la marque de temps utilisée par une entité.
On peut reconnaître par défaut le format ISO 8601 et accepter d’autres formats sous la forme d’un compteur. Ce compteur, dans ce cas doit avoir une forme progressive dans le temps pour pouvoir être interprétée au moins comme compteur à défaut de pouvoir en extraire une date fiable.
On peut reconnaître par défaut le format ISO 8601, accepter le compteur et accepter un indice de formatage spécifique pour des marques de temps autres. Le compteur doit toujours être progressif.
Enfin, on peut ne reconnaître que le compteur et une marque de temps préfixée de sont type. Cette dernière solution intègre à peu près les marques de temps actuellement utilisées dans nebule au format ISO 8601 comme de simples compteurs.

Echanges via http – suite

Dimanche, octobre 20th, 2013

Suite du post Echanges via http.

Si la définition des échanges dépend plus de nebule que de sylabe, c’est une erreur de mélanger les deux.

En effet, nebule a bien vocation à définir les téléchargements de liens et d’objets, notamment via http. La confusion vient que si sylabe passe par ce même protocole http vers les mêmes serveurs, les deux ne doivent pas être mélangés dans leurs rôles. Le projet sylabe doit être vu comme une application cliente qui repose notamment sur des échanges nebule mais doit utiliser ses propres accès pour son fonctionnement. C’est donc le cas pour lire les objets dans le navigateur web, surtout si ceux-ci ont nécessités d’être déchiffrés.

Les échanges via nebule ne doivent à aucun moment permettre le téléchargement d’objets nécessitant préalablement un déchiffrement.

Donc le programme index.php ne se chargera pas de gérer les translations de requêtes http (.htaccess pour Apache). Si sylabe (ou tout autre programme) en a besoin, il doit de lui-même mettre en place tout ce qui est nécessaire à son bon fonctionnement.

Comment rester sécurisé face à la NSA

Dimanche, septembre 22nd, 2013

En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Je vais me concentrer sur les 5 points, traduits ici :

  1. Caché dans le réseau. Implémentez des services cachés. Utilisez TOR pour protéger votre anonymat. Oui, la NSA cible les utilisateurs de TOR, mais cela est efficace sur eux. Moins vous serez à découvert, plus vous serez en sécurité.
  2. Chiffrez vous communications. Utilisez TLS. Utilisez IPsec. Encore une fois, bien qu’il soit vrai que la NSA cible les communications chiffrées (et ils connaissent peut-être des failles spécifiques contre ces protocoles), vous serez bien mieux protégés que si vous communiquez en clair.
  3. Prenez pour acquis que, bien que votre ordinateur puisse être compromis, cela nécessite du travail et représente un risque pour la NSA (donc il ne l’est probablement pas). Si vous avez quelque chose de vraiment important, utilisez un transfert par un moyen déconnecté. Depuis que j’ai commencé à travailler avec les documents de Mr Snowden, j’ai acheté un nouvel ordinateur qui n’a jamais été connecté à internet. Si je veux transférer un fichier, je chiffre le fichier sur l’ordinateur sécurisé puis l’emmène à pied jusqu’à mon ordinateur sur internet, sur une clé USB. Pour déchiffre quelque chose, j’inverse le processus. Cela ne doit pas être infaillible, mais suffisamment bon.
  4. Soyez méfiants envers les logiciels de chiffrement commerciaux, spécialement des grands éditeurs. Mon avis, c’est que la plupart des produits de chiffrement des grandes entreprises US ont des portes dérobées pour la NSA, et il est probable que les entreprises étrangères fassent de même. Il est prudent de considérer que les équipements étrangers aient aussi des portes dérobées pour une puissance étrangère. Il est plus facile pour la NSA de placer une porte dérobée dans un logiciel à sources fermées que dans un autre aux sources ouvertes. Les systèmes reposants sur un important secret sont vulnérables à la NSA, que ce soit pour leurs activités légales ou plus clandestines.
  5. Essayez d’utiliser des algorithmes de chiffrements dans le domaine public qui nécessitent d’être compatibles avec d’autres implémentations. Par exemple, il est plus difficile pour la NSA de placer une porte dérobée dans TLS que dans BitLocker. Parce que tous les implémentations de TLS doivent être compatibles entre elles alors que BitLocker ne doit être compatible qu’avec lui-même, donnant à la NSA plus de libertés pour apporter des changements. Et parce que BitLocker est propriétaire, il est beaucoup moins probable que ces changements soient découverts. Préférez la cryptographie symétrique plutôt que la cryptographie à clé publique. Préférez les systèmes conventionnels à logarithmes discrets plutôt que les systèmes à courbes elliptiques. Ces derniers ont des constantes que la NSA influence dès qu’elle le peut.

Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.

Confrontons donc maintenant le projet nebule et ces cinq points :

  1. Le projet nebule, une fois diffusé, peut être hébergé partout sur le réseau. Par défaut, les entités ont des emplacements connus. Mais rien n’empêche une entité d’avoir un emplacement dont l’objet contenant est chiffré, et l’URL d’une forme difficile à deviner même si on connaît le serveur. Par contre, si les objets et liens d’une entité sont échangés avec une autre entité, elle se retrouve à découvert sur d’autres emplacements. Ceci ne devrait cependant arrivé que si des liens relient ces objets aux deux entités. Le chiffrement des objets la seule parade définitive, ce qui est logique. L’anonymisation tel que proposé par TOR n’a pas de sens dans nebule.
  2. Dans nebule, on a le choix. Rien n’empêche de chiffrer toutes les informations vitales et de placer les liens suspects dans des objets chiffrés. Ce dernier point n’est pas encore implémenté mais est prévu et est techniquement réalisable. Utiliser TLS est recommandé au risque de révéler les liens et objets échangés, et donc d’affaiblir l’anonymisation.
  3. Le risque de l’ordinateur compromis est assez actuel malheureusement. Tant qu’un système ne sera pas intégralement nébulisé, le projet nebule n’apportera pas grand chose à ce niveau. On peut cependant profiter de la signature native des objets contre la modification malveillante. Par contre, nebule permet assez facilement de faire des échanges à sens unique, via des relais d’isolation, et via des supports amovibles. Et le chiffrement peut être entièrement réalisé sur un ordinateur isolé, même à destination d’une autre entité.
  4. Pour résumer, il faut utiliser des logiciels open sources et qui ne sont pas restreints à un seul éditeur dans leur utilisation. Le projet nebule par dès le début avec un choix d’utilisation par défaut de logiciels libres (et open sources). Ceux retenus sont très utilisés, et donc très régulièrement vérifiés. L’inter-opérabilité avec d’autres systèmes et implémentations est aussi à ce prix.
  5. Le début a les mêmes réponses que pour le point 4. Il est impossible de gérer des entités avec la cryptographie symétrique. La cryptographie asymétrique est irremplaçable. Mais il ne faut pas utiliser ces algorithmes pour faire des choses pour lesquels ils ne sont pas prévus. Par contre, si l’algorithme à logarithmes discrets est principalement utilisé aujourd’hui, tout algorithme peut être utilisé en parallèle ou en remplacement. Cela n’a pas d’importance structurelle forte. Le projet nebule s’appuie sur la cryptographie asymétrique pour les signatures et chiffrements (pour les clés de sessions).

Liens :
https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html

Echanges via http

Jeudi, septembre 12th, 2013

L’avancement de sylabe met en avant un manque de standardisation des échanges nebule via le protocole http. Cela impacte notamment directement le téléchargement et le suivi de liens u.

Il faut compléter la documentation de référence nebule v1.1 concernant les moyens et supports d’échange.

Comme la définition des échanges dépend plus de nebule que de sylabe, c’est naturellement le programme index.php qui se chargera de gérer les translations de requêtes http (.htaccess pour Apache).

Il en sera de même pour tout nouveau protocole d’échange lorsque le besoin s’en fera ressentir. Cela pourra être le cas par exemple pour le xmpp et le smtp