Cette note comporte un mix d’éléments humains et de considérations techniques. Selon la culture de chacun, elle peut apparaître comme une collection d’évidences ou de discours abscons.

Confiance humaine

Au delà de la pétition de principe que in fine tout aboutit à une confiance humaine, le plus important est d’analyser ce qui se passe si elle est prise en défaut.

On peut consacrer des moyens considérables à essayer de casser une clé de cryptage, mais le fait est que la corruption et la menace sur son propriétaire sont en général des procédés moins coûteux pour obtenir le même résultat.

Une structure non hiérarchique qui confine les conséquences des fuites des utilisateurs

Dans les structures dictatoriales, un sommet détient plus d’information que les niveaux inférieurs. Mais la structure de l’application n’est pas hiérarchique mais à plat, en réseau:

faire tomber la confidentialité d’un compte ne fait tomber qu’une partie de la confidentialité:
- celles des notes du compte,
- celles des groupes dont le compte est membre, notes et / ou liste des membres. Si les notes révèlent un contenu, la liste des membres ne révèlent que des cartes de visite où le propriétaire a mis ce qu’il voulait (et rarement son adresse postale et son identité réelle).
- celles des chats avec d’autres comptes, dont là encore le contenu de l’échange est connu et la carte de visite peut-être non fiable.
il semble très difficile d’imposer aux comptes de toujours inclure un responsable hiérarchique dans leurs groupes, sauf par une menace forte au cas où un compte récalcitrant se ferait prendre à ne pas le faire -ce qui reste aléatoire-.

En conséquence il n’y pas de moyens pour faire tomber en masse les comptes d’un espace en tapant sur une tête: la perte de confidentialité est toujours restreinte, ce qui confine les risques humains d’infiltration / corruption / menace.

Les agents techniques directs et de second niveau

Plusieurs agents techniques interviennent à différents niveaux, les conséquences de leurs défaillances sont analysés dans la suite de ce document:

le développeur : il a écrit le logiciel, est responsable du contenu de son source initial, pas des transformations et extensions qui peuvent se produire ensuite.
l’agent de déploiement de l’application Web : depuis le source de l’application Web il a configuré les adresses des services centraux à accéder et a déployé sur un site Web l’application pour qu’elle puisse être invoquée par les utilisateurs.
l’administrateur technique a effectué le travail équivalent pour déployer sur un serveur (pour simplifier) l’application serveur (les deux services des opérations et de push web).

Les agents de second niveau sont, en vue simplifiée, ceux des providers de service externes:

provider du site Web d’où l’application Web peut être invoquée.
provider du serveur central, ou des cloud functions correspondantes.
provider de la base de données responsable d’assurer la confidentialité des données qui y sont stockées.
provider du storage ou les fichiers attachés aux notes sont stockés.

Ce qui est analysé ci-dessous n’est pas la fiabilité / disponibilité de leurs prestations mais leur capacité à assurer la confidentialité vis à vis des autres bien entendu mais aussi d’eux-mêmes. Plus prosaïquement, le risque zéro n’existant pas,

comment déceler une éventuelle faille de confidentialité ?
que se passe-t-il, quelles conséquences, une faille (toujours possible) de confidentialité a-t-elle ?

Confiance technique de base

C’est celle que nous sommes obligés d’avoir dans certains éléments techniques, faute de quoi rien n’est possible. Quelques uns sont listés ci-dessus.

Le couple matériel / Operating System + browser des terminaux

Un terminal peut avoir des portes dérobées qui par exemple,

trace les frappes au clavier,
liste des données en mémoire de l’application en cours d’exécution, comme un debugger à distance non contrôlé par le propriétaire du terminal.

Sans confiance dans ces matériels / logiciels aucune confidentialité n’est possible à assurer: les textes à afficher sont en clair dans la mémoire des postes sinon … ils ne peuvent pas s’afficher, les clés de cryptage y sont aussi en clair sinon … elles ne peuvent ni crypter ni décrypter.

L’application Web permet de saisir sa phrase secrète sur un clavier applicatif: ceci empêche d’intercepter les frappes au clavier depuis un clavier hacké. Si c’est la mémoire du browser qui est accessible depuis l’extérieur, certes la saisie n’est pas interceptée mais son résultat l’est.

De la paranoïa ? Peut-être mais des mobiles piratés à distance ont fait l’actualité et la rumeur dit que les géants du Web ont leur propre version de Linux dans leurs serveurs pour éviter d’être hackés à leur insu.

Le couple matériel / Operating System des serveurs

Quand le serveur est hébergé par un provider externe, on en revient à la question plus générale d’avoir confiance en lui ou non.

Quand on est son propre hébergeur, la confidentialité est compromise si le provider de la VM (pour simplifier) a placé des portes dérobées permettant de lire les données en cours d’exécution dans les processus exécutant Node.

Conséquences des compromissions selon les niveaux / agents techniques

Données humaines versus meta-données

Les données humaines sont les textes et fichiers humainement interprétables,

les textes des notes et de leurs fichiers attachés, des chats, des cartes de visite et leurs photos,
par extension les clés de cryptage permettant de les crypter / décrypter.

Les identifiants des comptes, avatars, notes, chats, groupes … sont des chaînes de 12 chiffres / lettres latines minuscules et majuscules aléatoires. Un identifiant ne signifie rien tout seul.

Les meta-données sont des relations entre identifiants:

liste des avatars d’un compte,
liste des groupes accédés par un avatar / compte,
liste des invitations aux groupes d’un avatar / compte,
liste des comptes sponsorisés par un compte A en attente de réponse,
liste des contacts d’un avatar / compte,
liste des tickets de crédits d’un compte (leur numéros, pas leur contenu).

Par extension sont des meta-données,

les compteurs d’abonnement / consommation d’un compte,
la date de fin de validité d’un compte,
les numéros de version, le nombre de fois où un document (compte, avatar, note …) a été modifié.

Règles majeures

Aucune donnée humaine ne sort en clair de la mémoire d’une session de l’application Web en cours d’exécution sur un terminal.

même ce qui s’écrit sur la micro base de données locale est crypté par la clé majeure du compte.

Autrement dit à la double condition,

que le terminal soit techniquement digne de confiance,
que le logiciel de l’application Web qui s’y exécute n’ait pas subi de transformation depuis son source,

il est impossible de lire aucune données humaines sur aucun autre support technique que la mémoire d’une session.

Les meta-données ne sont lisibles en clair QUE dans la mémoire des serveurs en cours d’exécution:

les sessions en exécution dans un browser ont aussi en mémoire en clair les meta-données mais seulement celles relatives au périmètre du compte auxquels elles sont connectés.

La base données n’expose pas les meta-données, elles sont cryptées par la même clé qui permet à un serveur de les interpréter dans sa mémoire.

Conséquences sur le détournement de la base de données

Les meta-données n’y sont pas lisibles en clair: il faut en faire un extrait et les décrypter par la clé de l’administrateur technique.
Les données humaines sont inaccessibles, cryptées par les données des comptes.

Conséquences sur le détournement de l’espace de storage des fichiers

Il n’y a pas de meta-donnée stockées. Les contenus des fichiers sont cryptés et leurs path sont cryptés depuis les identifiants (organisation, ID d’avatar / compte, ID d’un fichier).

Problématique de confiance

On suppose que le matériel / Operating System est de confiance.

On suppose aussi que les algorithmes de hash et de cryptage sont fiables:

SHA-256 et PBKFD.
AES-256.
RSA-2048.

Aucune information publique ne permet aujourd’hui d’affirmer le contraire, du moins jusqu’à, peut-être, une diffusion massive de calculateurs quantiques.

Logiciels open source

Tous les logiciels utilisés par l’application sont open source, leurs sources peuvent être lus et analysés librement.

Ceci s’arrête aux frontières suivantes:

certains browsers sur les terminaux: Chrome n’est pas open source.
l’exécutable de Node sur les serveurs.
certains logiciels de base de données.

Ce n’est pas parce que le logiciel de l’application est open source que pour autant c’est celui-là qui s’exécute !

A partir de ces prémisses la confiance globale repose sur les points suivants:

l’application Web: celle en exécution est-elle celle originale ?
l’application Serveur: celle en exécution est-elle celle originale ?
la clé de cryptage de l’administrateur technique sur les serveurs est-elle restée secrète ?

Si les réponses à ces 3 questions sont OUI, la confiance dans l’application est acquise: les réponses dépendent de chaque choix de déploiement.

Dissociation entre l’application Web et les serveurs

Un serveur (pour simplifier, ce peut être des cloud functions) est joignable à partir de 3 données:

une URL pour invoquer les services OP (opérations),
une URL pour invoquer le service PUBSUB (web push des avis de modifications aux browsers),
une clé publique VAPID nécessaire pour faire fonctionner le web push.

Ces trois données,

sont spécifiques de chaque serveur,
ne sont pas confidentielles. Au pire un utilisateur malicieux tentera des connexions qui échoueront. Mais tout serveur est déjà toujours la cible potentielle d’une attaque par déni de service (saturation).

N’importe qui connaissant le dépôt github de l’application Web et ces 3 données pour un serveur S1, peut déployer sur un simple site Web statique l’application Web accédant à S1.

Par exemple github.com pages,

offre une capacité d’hébergement gratuite et publique de sites Web statiques,
l’habileté technique pour y déployer l’application Web est de faible niveau (pas de développement, mais savoir utiliser les lignes de commandes).

Une organisation peut parfaitement décider de procéder elle-même à ce déploiement sur ce qui sera son site d’où l’application Web peut être appelée par ses membres depuis un browser.

Voir en annexe la discussion sur la restriction éventuelle d’origine qu’un serveur peut mettre en place.

A la limite, un membre du groupe très suspicieux vis à vis de son organisation, peut tout à fait avoir son site, rien que pour lui ou quelques ami.e.s, de distribution de l’application Web.

Dans les deux cas il appartient à ceux qui ont déployé l’application Web à titre personnel ou de l’organisation de penser à la redéployer en cas d’évolution de ses sources.

Normalement un prestataire proposant un ou des serveurs, met aussi à disposition un site Web statique permettant à ses organisations clientes d’y accéder.

MAIS l’application Web distribuée est-elle celle originale ?

Depuis les sources d’origine, un agent de déploiement de l’application Web, peut,

soit utiliser la configuration par défaut: dans ce cas l’application distribuable est disponible directement sur le github.
soit vouloir ajuster certaines constantes de configuration dans le fichier de configuration. Il doit alors:
- obtenir l’application Web sur son poste de travail par un clone standard depuis le dépôt github.
- éditer localement sur son poste la configuration, voire avec prudence certaines traductions.
- enregistrer ces patchs dans le site de distribution afin que ceux qui le souhaitent puissent juger de leur non nocivité.
- procéder localement à un build, une pseudo compilation générant le code distribuable (ce qui prend environ une minute).

Une fois la distribution préparée, qu’elle ait été récupérée telle quelle ou après une configuration + build locale, il suffit de modifier dans le distribuable le fichier qui contient les trois données d’accès au serveur de son choix.

S’assurer en exécution que l’application Web distribuée sur le site n’a pas été patchée

Cas avec configuration par défaut

La distribution ne comporte que quelques fichiers, dont en fait 3 seulement sont sensibles. Ces fichiers peuvent être téléchargées depuis l’URL de distribution, sans même avoir un compte dans l’application ni à ouvrir l’application.

il suffit de vérifier qu’ils sont identiques à ceux du dépôt git source (outil standard de l’OS disponible sous Linux et Windows).

Cas avec configuration modifiée

Le site de distribution doit placer dans le répertoire de distribution un répertoire patch contenant les sources patchés.

il faut localement refaire un build en prenant les sources initiaux et les patchs.
il faut ensuite vérifier que les 3 fichiers distribuables sensibles sont conformes.

Conclusion

Il est simple de disposer de son propre site de distribution pour son organisation.

Il est aussi simple pour n’importe qui de s’assurer que ce site n’a pas été patché malicieusement.

Une structure indépendante de certification peut opérer et déclarer certifiées les nouvelles versions distribuées (ou prêtes à l’être).

Tout repose ensuite sur la confiance dans les agents ayant généré la distribution et en ceux l’ayant certifier (éventuellement soi-même). Toutefois la facilité de détection d’un comportement malicieux et le nombre de personnes capables de la vérifier réduit fortement le risque de piratage.

Dans ce contexte toutes les données humainement interprétables sont de confiance.

L’application Serveur: celle en exécution est-elle celle originale ?

L’administrateur technique a quelques opérations à exécuter pour déployer l’application Serveur depuis les sources certifiées disponibles sur git:

ajuster la configuration dans le fichier config,
ajouter les données secrètes qui ne sont pas dans git: tokens d’authentification vis à vis des providers, et quelques autres dont la clé de cryptage des données dans la base.
effectuer un build ou non selon les directives de son provider du service,
déployer le résultat chez son provider Serveur.

Le résultat de cette séquence est invérifiable:

une équipe externe de certification ne peut pas obtenir le résultat déployé chez le provider serveur,
elle ne peut donc pas s’assurer que le code initial n’a pas été patché à des fins répréhensibles.

Il est impossible de s’assurer en exécution que le code qui s’exécute sur le serveur est bien celui qui a été déployé: il faut faire confiance au provider du serveur. En effet techniquement un service qui s’exécute ne renvoie pas sur demande,

ni la signature du container Node qui s’exécute,
ni la signature du code déployé.

Les providers ayant pignon sur rue sont-ils de confiance ?

Clairement Google, Microsoft, Amazon Web Services ne s’amusent pas, ni à déformer le code distribué, ni à ouvrir des portes dérobées permettant de patcher / lire / tracer la mémoire des process en exécution.

techniquement ils peuvent le faire,
sur demande insistante d’une autorité de sécurité nationale, le feraient-ils ?

Alternative: assurer soi-même le rôle de provider serveur

C’est toujours possible et on peut toujours avoir son propre cloud privé où les VMs sont safe.

La question de confiance est ramenée à celle dans l’équipe d’administration … constituée d’humains corruptibles et pouvant subir des pressions, mais où un protocole de vérification humain est possible.

La clé de cryptage de l’administrateur technique sur les serveurs est-elle restée secrète ?

Cette clé permet à un intervenant extérieur ayant accès en lecture à la base de données, d’en lire les données dans les champs cryptés (colonnes _data_) qui contient les meta-données.

Le provider d’accès à la base de données est-il en mesure de lire tous les champs de la base ?

bien entendu, sinon il ne pourrait pas gérer la base,
mais les colonnes / attributs _data_ id ids hk ... ne lui sont accessibles qu’en binaire crypté dont il n’en a pas la clé. Il ne peut rien en faire et donc ne peut pas techniquement rendre visible les meta-données.

Remarque: l’administrateur technique gère la clé de cryptage et le jeton d’accès à la base. S’il détourne l’une il peut aussi détourner l’autre.

L’administrateur technique est en mesure technique de diffuser ces clés à un hacker qui sera en mesure d’accéder à la base et d’extraire / diffuser les meta-données.

Conclusion

Les données humaines ne sont accessibles que dans la mémoire des sessions en exécution de l’application Web.

c’est celle qui peut être le plus facilement certifiée par une équipe autonome de celle l’ayant déployée.
cette équipe peut s’assurer assez rapidement que le code déployé n’est pas malicieux, ni ne dirige vers des serveurs malicieux.

Il existe des moyens techniques et organisationnels pour s’assurer que les données humaines sont effectivement protégées.

Mais seule la confiance dans une chaîne organisationnelle permet d’estimer que le code qui s’exécute sur le serveur n’est pas malicieux. Cette même chaîne doit aussi s’assurer de la confidentialité du fichier donnant la clé de cryptage en base de donnes.

Si cette chaîne est jugée efficace, les meta-données sont aussi protégées.

Si ce n’est pas le cas, au pire les meta-données peuvent fuiter: on n’en tire pas grand-chose, seulement des relations entre identifiants aléatoires anonymes qui ne peuvent être vraiment exploités que s’ils sont rapprochés des personnes physiques et morales dans le vrai monde.

Annexe I: contrôler les origin dans un serveur

Le serveur peut être configuré pour n’accepter en entrée que des requêtes émises par des origines listées explicitement.

Un browser émet dans les requêtes sortantes un header origin comportant le nom de domaine et le port du site Web d’où il a chargé la page émettrice de la requête.

Un serveur peut spécifier quelles origin il accepte (ou toutes par défaut). C’est un moyen pour éviter que des sites Web parasites ne viennent soumettre des requêtes au serveur (par simplification l’autre header user-agent est passé sous silence).

Mais, ce n’est qu’une sécurité factice et qui ne contraint que ceux qui utilisent un site Web et un browser pour gérer l’application cliente.

Le contrôle de l’origine repose sur le fait que les browsers observent cette obligation, ce qui est le cas de ceux ayant pignon sur rue.

MAIS n’importe qui peut facilement écrire une application cliente, dans le langage de son choix, s’exécutant sur un poste, voire une application mobile, (mais pas dans un browser) qui écrira dans le header origin de ses requêtes ce qu’elle veut, typiquement l’une de celles attendues par le serveur.

Le serveur N’A AUCUN MOYEN de savoir si le header origin qu’il reçoit est bien une vraie origine écrite par un vrai browser fair ou celle produite par une application pirate qui s’est camouflée en browser.

En ce sens, l’agent de déploiement d’un serveur qui restreindrait les origines, typiquement à celles de son site délivrant l’application Web, n’apporte absolument aucune garantie de sécurité réelle: en revanche il bloque celles de ses organisations clientes ne lui faisant pas confiance aveugle pour l’application Web, ce qui d’une certaine façon n’est pas un signe incitant à la confiance.

Annexe II: peut-on authentifier un logiciel ?

Un matériel, un ordinateur, est identifiable: sa carte d’accès réseau a un identifiant absolu unique dans le monde par fabrication. Cet identifiant est accessible à tout logiciel s’exécutant sur le matériel en question.

toutefois il faut un logiciel pour transmettre cet identifiant à un serveur, et ce logiciel fait ce qu’il veut, en particulier transmettre un faux identifiant.

Un humain peut avoir des identifiants, login mots de passe / phrase secrète qui ont la caractéristique d’être externes aux ordinateurs qu’il utilise: sa mémoire cérébrale n’y est pas connectée (du moins aujourd’hui).

il faut bien un logiciel pour transmettre cette phrase secrète:
- d’abord ce n’est pas la phrase qui est transmise mais un hash (en fait deux) de cette phrase.
- ensuite le serveur peut savoir si oui ou non ce hash correspond à un compte chez lui, il peut croire avoir authentifié la personne ayant émis cette phrase (sans avoir à la connaître), mais en fait il n’en a authentifié qu’un hash.

Remarque: dans le cas de AsocialApp, si le serveur s’est fait berné en recevant un hash piraté, il renverra à l’application Web des données cryptés par la vraie phrase secrète entière (pas par son hash). Si l’application cliente pirate n’avait que les hash, elle ne peut rien en faire. La vraie phrase secrète en clair ne sort JAMAIS de la mémoire d’une session Web, il faut avoir hacké le browser pour l’exposer (ça arrive mais ce n’est pas très public et il faut savoir s’en servir et la faille ne vit pas forcément longtemps).

Un logiciel n’a pas d’identification inviolable.

son identifiant est forcément inscrit dans son code, il ne peut aller le chercher nulle part à l’extérieur.
s’il est dans le code, avec plus ou moins d’effort, on peut le retrouver. Tous les logiciels sont in fine décompilables, les langages de script plus facilement que les autres. Même quand l’identifiant est crypté dans le code, la clé de décryptage y figure aussi …

Tout cela pour dire qu’un serveur,

PEUT authentifier un HUMAIN à distance parce que l’identifiant en question est externe au matériel et au logiciel,
NE PEUT PAS AUTHENTIFIER un logiciel A qui communique avec lui parce que son identifiant étant inscrit dans le logiciel “A” lui-même peut être décompilé et réutilisé par un autre logiciel “B” qui pourra ainsi de faire passer pour “A” vis à vis du serveur.

L’application Web, ne peut pas, être authentifiée avec sûreté du fait même de la nature intrinsèque d’un logiciel qui est un texte lisible (humainement et par un CPU).