DGNum/gestioCOF

Fork 1

K-Psul : CNIL-compliant + user-friendly ? #238

New issue

Open

opened 2019-11-08 20:50:55 +01:00 by areitz · 7 comments

areitz commented

2019-11-08 20:50:55 +01:00

(Migrated from git.eleves.ens.fr)

La proposition part des constats suivants.

Les données relatives aux consommations sur trigramme des gens en général ne doivent pas rester accessibles pour une durée indéterminée, que ce soit par les personnes membres de l'équipe K-Fêt ou par les personnes membres de KDE.
Une personne donnée ayant un trigramme doit pouvoir faire le choix d'accéder aux données relatives à ses consommations, le tout de manière aisée. Le règlement des consommations en K-Fêt se faisant quasiment exclusivement en espèces, il n'est pas aberrant voire même carrément intéressant de simplifier l'accès à un tel marqueur/repère.
Des statistiques aussi anonymes que possibles doivent pouvoir être réalisées sur une échelle de plusieurs années pour estimer

Ce qui amène aux idées suivantes.

Les données relatives aux consommations sur trigramme des gens en général restent accessibles à l'équipe K-Fêt - donc via la base de données - pour une période fixée T, ni plus ni moins. Le système de trigrammes étant fondé sur la confiance, il paraît raisonnable de pouvoir régler un éventuel litige suite à une confusion lors de la saisie dans K-Psul.
Les possibilités suivantes ont été écartées, comme une solution qui respecte toutes les contraintes mentionnées existe. On suppose que les gens ont fait le choix de conserver leurs données de consommations.

Chaque personne ayant un trigramme reçoit (suite à un choix) après chaque intervalle de temps T un fichier comprenant l'ensemble de ses consommations sur la période considérée.
-> (a) Ne constitue pas un moyen aisé d'établir sur une période >> T des statistiques sur ses propres consommations. Fusionner des tableurs = pénible. (b) Implique une trace par mail.
Les données considérées restent (suite à un choix) en base de données sans se prendre la tête plus que ça, l'historique des consommations d'une personne étant accessible par K-Psul seulement par cette personne.
-> Peu sain, car accès encore possible pour les développeurs, y compris mettons à un historique qui peut remonter jusqu'à il y a des années.
Une meilleure idée semble être d'utiliser du chiffrement asymétrique avec déchiffrement client-side, de manière à ce que les personnes concernées puissent accéder à leurs données sur la période qu'ils veulent de manière pratique, en un seul bloc, sans que n'importe qui d'autre qu'eux-mêmes y ait accès.

D'où les propositions suivantes, plus techniquement concrètes.

Pour limiter la charge, les opérations pour supprimer les consommations des gens remontant à une date antérieure à la date courante - T seraient réalisées par blocs, à un intervalle de temps régulier T' < T. On peut imaginer une période de maintenance une fois par semaine, mettons le lundi entre 4 et 5h (une heure c'est large).
Supprimer veut ici dire supprimer de l'historique global de K-Psul.
Lors de la création d'un trigramme, un mail est envoyé au clipper correspondant (cf #237).
Dans ce mail serait inclus la politique de conservation des données de la K-Fêt, avec un lien pour modifier ses choix. Deux possibilités sont alors données :

Rien n'est conservé après une période T. (choix par défaut)
Données conservées : un mot de passe serait alors demandé, pour générer une paire (clé publique, clé privée) correspondante.
Lors de la "suppression" mentionnée dans l'item précédent, les données concernées par cette conservation protégée serait simplement rajoutée aux données déjà protégées du même trigramme.
(On peut imaginer une simple liste de données chiffrées.)

Au-delà de la mise en place ou non d'un tel patch (je suis prêt à m'en charger), il reste pour moi deux choses à discuter :
a) la bonne manière de générer/sécuriser une paire (clé publique, clé privée) à partir d'un mot de passe ;

b) à quel point il faut redemander chaque année à tous les gens qui ont un trigramme qui ont choisi l'année précédente de conserver leurs données de refaire ce choix, pour éviter une conservation ad vitam aeternam ; si au bout de x jours (un mois ?), il n'y a pas de réponse, les données correspondantes seraient supprimées.

a) Le sujet suivant semble répondre à la question.
https://crypto.stackexchange.com/questions/1662/how-can-one-securely-generate-an-asymmetric-key-pair-from-a-short-passphrase
Le plus canonique semble de générer une paire (clé publique, clé privée) de manière classique, et d'ensuite chiffrer la clé privée avec un algo de chiffrement symétrique, dont la clé est une donnée dérivée déterministiquement à partir du mot de passe.
A la saisie du mot de passe, la clé privée serait déchiffrée en premier client-side, pour ensuite déchiffrer (toujours client-side) les données de consommations de la personne concernée.
Je ne vois pas mieux, mais je pense que ça reste à discuter avec quelqu'un de plus compétent.

b) A discuter en réu.

Pour conclure, si cette proposition paraît inutilement compliquée par rapport à une supposée faible demande, j'ai plusieurs choses à dire :

pas mal de K-Fêteux.ses (mais pas que !) regardent l'historique de leur consommation, notamment pour évaluer a posteriori leur rapport à l'alcool pendant une période compliquée, et je pense que c'est absolument important de conserver cette possibilité ;
au final, les opérations considérées sur la base de données sont orthogonales au fonctionnement habituel de K-Psul, au sens où ça rajoute "seulement" des opérations de maintenance (hebdomadaires ou autres) ;
il existe de bonnes librairies de crypto en JavaScript qui rendent le tout raisonnablement faisable.

Je suis prêt à m'occuper de tout ceci et j'attends vos commentaires. :)

La proposition part des constats suivants. 1) Les données relatives aux consommations sur trigramme des gens en général ne doivent pas rester accessibles pour une durée indéterminée, que ce soit par les personnes membres de l'équipe K-Fêt ou par les personnes membres de KDE. 2) Une personne donnée ayant un trigramme doit pouvoir *faire le choix* d'accéder aux données relatives à ses consommations, le tout *de manière aisée*. Le règlement des consommations en K-Fêt se faisant quasiment exclusivement en espèces, il n'est pas aberrant voire même carrément intéressant de simplifier l'accès à un tel marqueur/repère. 3) Des statistiques *aussi anonymes que possibles* doivent pouvoir être réalisées sur une échelle de plusieurs années pour estimer Ce qui amène aux idées suivantes. 1) Les données relatives aux consommations sur trigramme des gens en général restent accessibles à l'équipe K-Fêt - donc via la base de données - pour une période fixée T, ni plus ni moins. Le système de trigrammes étant fondé sur la confiance, il paraît raisonnable de pouvoir régler un éventuel litige suite à une confusion lors de la saisie dans K-Psul. 2) Les possibilités suivantes ont été écartées, comme une solution qui respecte toutes les contraintes mentionnées existe. On suppose que les gens ont *fait le choix* de conserver leurs données de consommations. - Chaque personne ayant un trigramme reçoit (suite à un choix) après chaque intervalle de temps T un fichier comprenant l'ensemble de ses consommations sur la période considérée. -> (a) Ne constitue pas un moyen aisé d'établir sur une période >> T des statistiques sur ses propres consommations. Fusionner des tableurs = pénible. (b) Implique une trace par mail. - Les données considérées restent (suite à un choix) en base de données sans se prendre la tête plus que ça, l'historique des consommations d'une personne étant accessible par K-Psul seulement par cette personne. -> Peu sain, car accès encore possible pour les développeurs, y compris mettons à un historique qui peut remonter jusqu'à il y a des années. Une meilleure idée semble être d'utiliser du chiffrement asymétrique avec déchiffrement client-side, de manière à ce que les personnes concernées puissent accéder à leurs données sur la période qu'ils veulent de manière pratique, en un seul bloc, sans que n'importe qui d'autre qu'eux-mêmes y ait accès. D'où les propositions suivantes, plus techniquement concrètes. 1) Pour limiter la charge, les opérations pour supprimer les consommations des gens remontant à une date antérieure à la date courante - T seraient réalisées par blocs, à un intervalle de temps régulier T' < T. On peut imaginer une période de maintenance une fois par semaine, mettons le lundi entre 4 et 5h (une heure c'est large). Supprimer veut ici dire supprimer de l'historique global de K-Psul. 2) Lors de la création d'un trigramme, un mail est envoyé au clipper correspondant (cf #237). Dans ce mail serait inclus la politique de conservation des données de la K-Fêt, avec un lien pour modifier ses choix. Deux possibilités sont alors données : - Rien n'est conservé après une période T. *(choix par défaut)* - Données conservées : un mot de passe serait alors demandé, pour générer une paire (clé publique, clé privée) correspondante. Lors de la "suppression" mentionnée dans l'item précédent, les données concernées par cette conservation protégée serait simplement rajoutée aux données déjà protégées du même trigramme. (On peut imaginer une simple liste de données chiffrées.) Au-delà de la mise en place ou non d'un tel patch (je suis prêt à m'en charger), il reste pour moi deux choses à discuter : a) la bonne manière de générer/sécuriser une paire (clé publique, clé privée) à partir d'un mot de passe ; b) à quel point il faut redemander chaque année à tous les gens qui ont un trigramme qui ont choisi l'année précédente de conserver leurs données de refaire ce choix, pour éviter une conservation ad vitam aeternam ; si au bout de x jours (un mois ?), il n'y a pas de réponse, les données correspondantes seraient supprimées. a) Le sujet suivant semble répondre à la question. https://crypto.stackexchange.com/questions/1662/how-can-one-securely-generate-an-asymmetric-key-pair-from-a-short-passphrase Le plus canonique semble de générer une paire (clé publique, clé privée) de manière classique, et d'ensuite chiffrer la clé privée avec un algo de chiffrement symétrique, dont la clé est une donnée dérivée déterministiquement à partir du mot de passe. A la saisie du mot de passe, la clé privée serait déchiffrée en premier client-side, pour ensuite déchiffrer (toujours client-side) les données de consommations de la personne concernée. Je ne vois pas mieux, mais je pense que ça reste à discuter avec quelqu'un de plus compétent. b) A discuter en réu. Pour conclure, si cette proposition paraît inutilement compliquée par rapport à une supposée faible demande, j'ai plusieurs choses à dire : - pas mal de K-Fêteux.ses (mais pas que !) regardent l'historique de leur consommation, notamment pour évaluer a posteriori leur rapport à l'alcool pendant une période compliquée, et je pense que c'est absolument important de conserver cette possibilité ; - au final, les opérations considérées sur la base de données sont orthogonales au fonctionnement habituel de K-Psul, au sens où ça rajoute "seulement" des opérations de maintenance (hebdomadaires ou autres) ; - il existe de bonnes librairies de crypto en JavaScript qui rendent le tout raisonnablement faisable. Je suis prêt à m'occuper de tout ceci et j'attends vos commentaires. :)

areitz commented

2019-11-08 20:52:09 +01:00

(Migrated from git.eleves.ens.fr)

made the issue confidential

areitz commented

2019-11-08 20:53:43 +01:00

(Migrated from git.eleves.ens.fr)

changed the description

areitz commented

2019-11-08 21:15:30 +01:00

(Migrated from git.eleves.ens.fr)

La réponse à ce constat est simple : éventuellement sauvegarder (agréger en gardant une certaine granularité serait mieux, mais c'est pas parfait, cf differential privacy) les transactions sans que le moindre identifiant y soit rattaché.

3. La réponse à ce constat est simple : éventuellement sauvegarder (agréger en gardant une certaine granularité serait mieux, mais c'est pas parfait, cf differential privacy) les transactions sans que le moindre identifiant y soit rattaché.

areitz commented

2019-11-08 21:18:12 +01:00

(Migrated from git.eleves.ens.fr)

changed the description

mpepin commented

2019-12-20 16:23:20 +01:00

(Migrated from git.eleves.ens.fr)

Après plus mûre réflexion, j'ai une objection dont je voudrais discuter.

Ça part du constat qu'inévitablement les sysadmins voient passer toutes les données de façon non chiffrée, au moment de la commande notamment.

Pour moi ça pose la question suivante : quelle différence y a t il entre

chiffrer comme décrit plus haut,
ou ne rien chiffrer mais tout afficher de façon anonymisée dans l'historique ?

Après plus mûre réflexion, j'ai une objection dont je voudrais discuter. Ça part du constat **qu'inévitablement** les sysadmins voient passer toutes les données de façon non chiffrée, au moment de la commande notamment. Pour moi ça pose la question suivante : quelle différence y a t il entre 1. chiffrer comme décrit plus haut, 2. ou ne rien chiffrer mais tout afficher de façon anonymisée dans l'historique ?

pnmadela commented

2020-07-13 16:35:58 +02:00

(Migrated from git.eleves.ens.fr)

mentioned in merge request !431

mpepin commented

2020-12-04 20:11:48 +01:00

(Migrated from git.eleves.ens.fr)

mentioned in issue #284

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: DGNum/gestioCOF#238

No description provided.