Post on 11-Apr-2018
Gestion de données personnelles
respectueuse de la vie privée
Nicolas Anciaux, Chercheur INRIA, projet SMIS
équipe commune: INRIA Rocquencourt,
Univ. de Versailles Saint-Quentin-en-Yvelines,
et CNRS
Habilitation à Diriger des Recherches
Univ. de Versailles Saint-Quentin-en-Yvelines
Le 9 décembre 2014
1
PR SM
Thèse (UVSQ)
Post doc (U.Twente)
PicoDBMS
Co-design de SGBD embarqué
Benchmark
Traitements BD privées/publiques
GhostDB
Traitements relationnel embarqués
Archi. gestion de données PbD
PlugDB
Collecte et rétention limitée
MinExpCard
Moteur NoSQL/CA embarqué
Modèle de partage (WPS)
Contrôle d’usage
H. van Heerde
(2005-2010)
Y. Guo
(2008-2011)
L. Le Folgoc
(2009-2012)
S. Lallali
(2012-…)
P. Tran Van
(2014-…)
L. Bouganim
P. Pucheral
J.C. Marchetaux
D. Shasha
J.-J Vandewalle
Ij. & Ik. Ray
M. Vazirgiannis
B. Nguyen
P. Bonnet
CR2 INRIA
(CR1 2008)
Vie privée et intelligence Ambiante
Modèle BD de dégradation progressive
InstantDB
P. Apers
L. Feng
M. Fokkinga
Doctorants Collaborations 2000
2005
2006
2008
2010
2012
2014
2
PR SM
Plan de la présentation
Motivation des travaux de recherche : Web Personnel Sécurisé
Contributions et applications
I) Architectures envisagées
II) Evaluation de requêtes embarquée
III) Exposition minimum
IV) Application au « Dossier Médico-Social Personnel »
Conclusion et perspectives
3
PR SM
Le modèle du Web actuel
Données durables et accessibles
Délégation (enjeu de vie privée)
Ouverture et opt-out non garantis
Dissémination sans garantie pour l’usager
Chartes floues, passe-droits, usages secondaires
Centralisation (enjeu de sécurité)
Une simple négligence compromet des millions de dossiers
Attaques massives récurrentes (ratio coût/bénéfice faible)
Ex: Orange 1,3M mai 2014, 800K mars 2014
Cloisonnement (enjeu de complétude)
Stratégie monopolistique
Technique d’appariement contestable
4
Social Photos
Mail Banque
Achat
Pub. ciblée Profilage
PR SM
Le modèle du Web Personnel
Rend leurs informations aux usagers
Encouragé par des organismes (banques)
Par les institutions (opération Blue Button)
CozyCloud, OpenPDS, PlugDB…
Complétude de fait
Nouveaux usages
Vie privée sous contrôle
Ouverture et opt-out de fait
Partage contrôlé, exposition minimale
Calculs globaux anonymes
5
Social Photos
Mail Banque
Achat
Pub. ciblée Profilage
Coordination
médico-sociale
Exposition
minimale
Capteurs Localisation
«Quantified-self»
Calcul global anonyme
PR SM
Notre approche: un Web Personnel Sécurisé
Comment rendre ses données à l’usager ?
Sur son PC ? un service Cloud ?
Un serveur personnel propriété de l’individu…
Dépositaire du patrimoine numérique d’un individu
Régulant la dissémination des données
… intégrant des fonctionnalités de gestion de données
Stockage, indexation, structuration et durabilité des données
Authentification, contrôle d’accès et d’usage
Auto-administré
… et offrant des garanties de sécurité tangibles
Noyau logiciel sécurisé : code réduit , prouvé formellement, open source
Plateforme matérielle : isolée de la plateforme applicative, sécurisée
matériellement, open hardware
6
PR SM
Plan de la présentation
Motivation des travaux de recherche
Contributions et applications
I) Architectures envisagées
II) Evaluation de requêtes embarquée
III) Exposition minimum
IV) Application au « Dossier Médico-Social Personnel »
Conclusion et perspectives
7
PR SM
Architecture « Serveur Personnel de Données »
Approche institutionnelle
Monde structuré
Par domaines applicatifs
Données: format régulé
Normes, référentiels communs
Droits d’accès: institutionnels
L’individu garde un droit au masquage
«Honnêtes mais curieux»
Chiffrement, comm. anonymes
Défis scientifiques
Gestion de données embarquées,
durabilité, partage (exposition
minimum, masquage, audit),
évaluation globale …
8
Personal
database
John
Content
provider
Document
Wrapper
DBMS
Mapping
rules
<DOC>
<Id> 7 </>
<name> Jim </>
~~~~~~~~~~~~~ </></>
<DRUG>
<Id> 45</>
<name> Mucomist</>
~~~~~~~~~~~~~ </></>
<VISIT Id = “X”>
<Date> 2010/1/1</>
<DocRef>7</>
~~~~~~~~~~~~~ </></>
<PRESCS>
<VisitId Ref=“X”/>
<DrugRef>45</>
<Posology> 3/day</></>
Enriched XML
document
XML Schema e.g.,
hospital
John’s PDS
Application
Appli.
provider
Doctors,
Drugs
conforme
Honest but curious
Encrypted storage
Anonymous comm.
e.g., Santeos
Application
Mappings Mappings
Priviledges Priviledges
DB Schema
provider e.g., Ministry
of Health
[VLDB’10]
PR SM
Architecture « Cellules de confiance »
Centrée sur l’usager
Nombreux dispositifs produisent
des données sur l’individu
Données diverses
Personnelles, issues de capteurs, …
Droits d’accès et d’usage
Définis par l’individu
Infrastructure
«faiblement malicieuse»
Défis scientifiques
Collecte contrôlée (capteurs de
confiance), auto-administration,
contrôle d’usage (UCON*ABC)
9
A
A & B services
A
A Power
provider
Super-
market
Car insurer
B
Syn
c.
A
Portable Trusted Cell Encrypted personal vault Secure data exchange
Ph
oto
s
MyF
iles
Syn
c.
Fixed Trusted Cell S
yn
c
.
Heat sensor
Power meter
F E
D H
G
I C
Internet
café
A & B home
D
E F
H
I
G
B
A
Employer
Hospital
School
C
C
GPS
Weakly malicious
[CIDR’13]
*Obligation, conditions, mutabilité
PR SM
Architectures: conclusion et résultats
Ouvrent à de nombreux défis scientifiques
Gestion de données embarquée
Contrôle de la dissémination des données : exposition minimale
Objectif actuel
Une architecture pour le Web Personnel Sécurisé
2010
2014
2013
Serveur Personnel de Données : VLDB’10
Cellules de confiance : CIDR’13
Archi. avec matériel sûr : tutoriel MDM’13
tutoriel EDBT’14
Folk-IS: papier vision VLDB’14, SIG. record’14
Thèse de Y. Guo (2011)
Thèse de L. Le Folgoc (2012)
Thèse P. Tran Van (CIFRE CozyCloud)
10
PR SM
Plan de la présentation
Motivation des travaux de recherche
Contributions et applications
I) Architectures envisagées
II) Evaluation de requêtes embarquée
III) Exposition minimum
IV) Application au « Dossier Médico-Social Personnel »
Conclusion et perspectives
11
PR SM
Objectif et matériel cible
Gérer des données personnelles dans un composant sécurisé
Volume de données potentiellement grand
e-mails, documents personnels, médicaux, administratifs, données d’interractions, issues de
capteurs, trace GPS, de consommation énergétique, etc.
Des techniques d’évaluation de requêtes embarquées doivent
permettre de n’exposer que des résultats autorisés
Les composants cibles peuvent avoir des formes diverses
12
Secure devices on which
a GB flash chip
is superposed
USB MicroSD
reader
Contactless + USB
8GB Flash
Secure MicroSD
4GB Flash
Personal memory devices
in which a secure chip is implanted
Multimedia
Sim Card Sensor node
PR SM
Gestion de données: une architecture commune
Microcontrôleur
Faible coût
Faible consommation d’énergie
Protection matérielle
Miniaturisation
Maillage (porteur d’un signal),
Couches de composants superposées,
Capteurs (lumière/temp./freq./voltage)
Prévient les attaques physiques
Mémoire de type NAND FLASH
Faible coût
Faible consommation d’énergie
Densité et robustesse
NAND
FLASH
MCU
BU
S
13
PR SM
Contraintes matérielles fortes… mais pérennes
Les microcontrôleurs ont une petite RAM (<128 KB)
Elle est alimentée => consommation énergétique (lié à la quantité)
Elle détermine le prix du microcontrôleur
La RAM n’est pas dense => nuit à la sécurité (liée à la taille)
Ecritures aléatoire coûteuses en Flash (10-500ms carte SD)
Fonctionnement de la Flash: les pages sont effacées avant toute
modification, l’effacement est par bloc vs. écriture par page
Pour compenser ces effets il faudrait de la RAM (cas d’un SSD...)
Or dans l’embarqué, le ratio RAM/mémoire stable ne fait que diminuer
Contraintes durables pour tout dispositifs
autonome, à bas coût (capteurs, carte SD)
ou sécurisé (puce sécurisée ou “durcie”)
14
PR SM
Techniques existantes
SGBD légers
e.g., SQLite, BerkeleyDB, DB2
Everyplace, …
Vise des plateformes plus puissantes
(e.g., smart phones, boîtes Internet)
Indexation de BD en Flash
Adaptation de l’index B+: BFTL [TECS07],
LATree [VLDB09], FDTree [VLDB10]
Stocke les mises à jour de l’index dans
un journal en Flash, indexé en RAM
Les mises à jour sont intégrées à l’index
en batch pour factoriser des écritures
Petite RAM petit index en RAM
intégration fréquente du journal
gains minimes
Systèmes clé-valeur en Flash
SkimpyStash [SIG11], LogBase [VLDB12],
SILT [SOSP11]
Les couples clé-valeur sont stockés dans
un journal en FLASH
Un index en RAM est construit sur ce
journal (~1 octet par couple clé-valeur)
Gestion de données pour MCUs
e.g. PicoDBMS [VLDBJ01], VSDB [TOIS03],
HybridStore [WSN13]
Considère de petits volumes de données
stockés en mémoire interne (EEPROM,
NOR)
Proposition en RI, e.g., MAX [TSN08],
Snoogle [TPDS10], Microsearch
[TECS10]
RAM FLASH
RAM
RAM
15
PR SM
Formulation du problème
Objectif : évaluer des requêtes avec très peu de RAM sur de
grandes quantités de données stockées en FLASH NAND
Comment rompre ce cercle vicieux ?
De nombreuse écritures aléatoires
… avec un coût inacceptable
en Flash Maintenance des index
indexation
massive
Evaluer des requêtes
avec une petite RAM
Stratégie Pipeline
Consomme trop de RAM
Journalisation en Flash
Indexation du journal en RAM
16
PR SM
Notre approche pour résoudre le problème
1- Concevoir des index permettant une évaluation pipeline
2- Organiser toute la BD dans des structures sequentielles
Des containers séquentiels (LC) satisfont les contraintes de la Flash
Allocation & libération réalisées à très gros grain (taille multiple d’un bloc de Flash)
…. de manière à éviter tout émiettement de la mémoire (ramasse miettes coûteux)
Les pages du container sont écrites séquentiellement (et jamais modifiées ni déplacées)
…. de manière à proscrire les écritures aléatoires par construction
3- Passer à l’échelle par réorganisations successives de la BD
Les structures séquentielles sont réécrites en structures plus efficaces
… l’opération de transformation repose sur des containers séquentiels
17
PR SM
Evaluer des requêtes SQL en pipeline
LIN
PS ORD
SUP CUS PAR
Project
Intersect
merge
{LINid}
Tselect sur SUP.Name
{LINid}
Tselect
access ‘SUPPLIER-1’
{LINid , CUSid,
ORDid, PSid}
Tjoin
access
Tjoin sur LIN
Plan d’exécution
Tselect
access
{LINid}
‘HOUSEHOLD’
Tselect sur CUS.Mktsegment
Tjoin on LIN
LIN
id
OR
Did
CU
Sid
PS
id
PA
Rid
Tjoin (index de jointure généralisé)
chaque rowid de la table
racine contient les
identifiants des tuples des
dimensions référencées
SU
Pid
Tselect sur
SUP.Name
Tselect chaque clé de l’index contient
les rowid de la table racine
référencant cette clé
NB: Tselect renvoie
des rowid triés!
Tselect sur
CUS.marketsegment
t20 t50 t30
K1
K2 … … …
… …
Kn
HOUSE HOLD
SELECT CUS.*, ORD.*, LIN.*, PARTSUP.*
FROM CUSTOMER CUS, ORDER ORD, LINETEM LIN, PARTSUP PS, SUPPLIER SUP
WHERE CUS.CUSkey = ORD.CUSkey AND ORD.ORDkey = LIN.ORDkey AND
LIN.PSkey = PS.PSkey AND PS.SUPkey = SUP.SUPkey AND
CUS.Mktsegment = 'HOUSEHOLD' AND SUP.Name = 'SUPPLIER-1'
Table
racine
‘HOUSEHOLD’ ‘SUPPLIER-1’
18
[SIGMOD’07, EDBT’09]
PR SM
Construire un index à base de containers séquentiels
Log2: «Keys» (colonne)
Stocke la clé de l’index à l’insertion du tuples
Log1: «Ptrs»
Stocke une chaîne de pointeurs
Log3: «Filtres de Bloom»
1 FB construit par page de «Keys»
Résumé de la page (2 octets / clé)
Table scan
(640 IOs)
CUSTOMER … … … Joe
… … … Jack
… … … … … … … Paul
… … … … … … … … … … … Jim
… … … … … Tom
… … … …
… … … Lyon
… … … Lyon
… … … … … … … Lyon
… … … … … … … … … … … Lyon
… … … … … Lyon
… … … …
t20
t50
t70
t90
t30
Summary Scan
(17 IOs)
Keys
Log2
… Lyon …
Lyon … … …
Lyon … … … … …
Lyon … …
Lyon … …
Indexed
column
CITY
P16
P78
B.Filters
Log3
Recherche efficace… … mais comment permettre un passage à l’échelle ?
Ptrs
Log1
… BF2 …
BF16 …
BF68 … …
BF79 …
19
[EDBT’14]
PR SM
Assurer le passage à l’échelle de toute la BD
Réorganisation de la BD dans des structures plus efficaces
La réorganisation est une opération purement séquentielle
20
Sta
rt r
eo
rgan
izati
on
DEL2 / UPD2 DATA2
IND1 DEL1 / UPD1
DATA1
ReorgIndex
Merge
*IND1
ReorgIndex
Merge
*DATA0
*DATA1
En
d r
eo
rgan
izati
on
IND0 DEL0 / UPD0
DATA0
Sta
rt r
eo
rgan
izati
on
*IND0
IND2
En
d r
eo
rgan
izati
on
Time
Insta
nce 0
In
sta
nce 1
In
sta
nce 2
[EDBT’14]
PR SM
Design d’un SGBD embarqué pour grosses BD Flash
Travaux actuels
Généralisation de nos techniques aux modèles NoSQL
et à des modèles de contrôle d’accès basés sur des tags
2007
2014
2011
2015
Evaluation embarquée : conclusion et résultats
Design initial (RO) : SIGMOD’07, Démo VLDB’07
Calcul d’agrégats : DAPD’09
Design DMSP : Démo SIGMOD’10
Design SGBDR complet : DAPD’14
Moteur de recherche : VLDB’15 (2eme round)
Démo SIGMOD’15 (soumis)
PlugDB-engine (déposé à l’APP)
Thèse de Y. Guo (2011)
Thèse de L. Le Folgoc (2012)
Thèse S. Lallali (en cours)
Transfert PlugDB CozyCloud
21
PR SM
Plan de la présentation
Motivation des travaux de recherche
Contributions et applications
I) Architectures envisagées
II) Evaluation de requêtes embarquée
III) Exposition minimum
IV) Application au « Dossier Médico-Social Personnel »
Conclusion et perspectives
22
PR SM
Collecte et rétention limitée des données
Principe législatif univoque (OCDE 1980, directive EU95/46/EC)
Limiter la collecte et la rétention des données au nécessaire
Scénario d’usage
Un individu fournit des données personnelles (en guise de preuve)
Des services sont calibrés selon ces données
Ex. collecte par formulaire
Aides sociales, banques, assurances…
Le minimum de données
doit être collecté…
Ces principes ont aussi des avantages pour les organismes
Traitement des demandes accéléré (CG78)
Coût réduit en cas de fuite de données (lié au volume de données)
Sentiment de « sur-collecte » ressenti par 50% des citoyens EU
23
Offre de service
Formulaire complet
Jean 83 ans beaucoup d’inform- -ations
Formulaire vierge
PR SM
Techniques existantes
Pour les sites Web : P3P (contribution pionnière)
Principes du “besoin d’en connaître” et du consentement pour les sites web
Identifie des politiques conflictuelles, ne calibre pas l’information exposée
Bases de données hippocratiques (IBM)
Fait l’hypothèse que les données nécessaires sont connues à l’avance
Ne tient pas si l’utilité de la donnée dépend de son contenu (fréquent)
Ce qui est le cas de nos scénarios d’usage…
Négociation automatique et modèles ouverts de contrôle d’accès
Les attributs sont exposés à minima
Requêtes simples
Quelques attributs échangés
24
Bob Alice
Credentials
Disclosure policies
Resource R
Access control
policy
Credentials
Disclosure policies
Computes
minimum
set
SMC
PR SM
Architecture à collecte minimum
Ingrédients
Règles de collectes (proc. de décision) :
Assertions individuelles:
attribut=valeur
Métrique d’exposition:
nombre d’assertions
Problème:
Trouver l’ensemble minimum d’assertions qui valide les règles
25
salaire>30K€ patrimoine>100K€
garantie>50K€ ass_vie=oui prêt+élevé
salaire>30K€ taux_impots>10%
age<30 niveau_etude=univ. assur_reduite
Offre de service
Jean 83 ans beaucoup d’inform- -ations
Règles de collecte Formulaire vierge
Minimisation
du contenu
du formulaire
Formulaire minimum
PR SM
Solutions
Solution exacte
Min Weighted SAT (NP-Complet)
Résolution par solveur trop longue (>100 assertions)
Solution approchée
Heuristiques adaptées aux topologies réelles
Règles d’attribution des aides sociales (CG78) : 63 règles, 440 prédicats
Jeux de données multi labels publiques
Réduction d’information toujours importante (> 40% vs. état de l’art)
Algorithmes simples (linéaires dans le nombre de prédicats)
…. et fonctionnant avec très peu de RAM (quelques Ko)
Proto. carte à puce : confrontation confinée des règles et des données
En quelques secondes pour les plus grandes instances considérées (>600 prédicats)
26
[PST’12, EDBT’13]
PR SM
Exposition minimum : conclusion et résultats
L’intérêt de notre solution
Spectre très large (support des classifieurs multi-labels)
Exécution sécurisée (règles privées)
Décision finale préservée
Travaux actuels
Nouvelle modélisation du problème pour capturer certaines inférences :
Connaissance des règles de collecte (non satisfaites)
Connaissance antérieure (formulaires déjà transmis)
Connaissance de l’algorithme de réduction
27
2012
2015
Problème d’exposition minimum : PST’12
Version étendue (règles plus riches): ISI’13
Application à l’aide sociale : Démo EBDT’13
Classifieurs multi-labels : Fund. Informatica’15
Collab. B. Nguyen & M. Vazirgiannis
Tangente’14
IREP, MyProfile => fidélité
PR SM
Plan de la présentation
Motivation des travaux de recherche
Contributions et applications
I) Architectures envisagées
II) Evaluation de requêtes embarquée
III) Exposition minimum
IV) Application au « Dossier Médico-Social Personnel »
Conclusion et perspectives
28
N. Anciaux – soutenance HDR
Coordination médico-sociale
Personne dépendante
Domicile
DMP, serveurs (ALDS, Cogitey), équipements personnels, outils domotiques…
29
Acteurs
médecins, infirmières, kinés, assistantes sociales, porteurs de repas,
aides journalière,
entourage…
Systèmes
Besoins exprimés :
• Dossier complet (à domicile, en consultation)
• Respectant des règles d’accès différenciées
• Synchronisé avec des chaînes de traitements
N. Anciaux – soutenance HDR
Solution 1 : dossier papier au chevet
Personne dépendante
Domicile
30
Acteurs
Systèmes
Dossier complet (au chevet, en consultation)
Aucune confidentialité
Doubles saisies
Ne capture pas l’information domotique
DMP, serveurs (ALDS, Cogitey), équipements personnels, outils domotiques…
médecins, infirmières, kinés, assistantes sociales, porteurs de repas,
aides journalière,
entourage…
N. Anciaux – soutenance HDR
Solution 2 : dossier centralisé
Personne dépendante
Domicile
31
Acteurs
Systèmes
Dossier complet (connexion Internet)
Pas de double saisie
Problème du consensus transverse (santé, social, public, privé, etc.)
Sentiment de Défiance, surveillance (délégation & centralisation)
Connexion internet itinérante pour tous (porteurs de repas, ménagères…)
DMP, serveurs (ALDS, Cogitey), équipements personnels, outils domotiques…
médecins, infirmières, kinés, assistantes sociales, porteurs de repas,
aides journalière,
entourage…
N. Anciaux – soutenance HDR
Solution DMSP : dossier patient
Domicile
32
Acteurs
Systèmes
Personne dépendante
DMP, serveurs (ALDS, Cogitey), équipements personnels, outils domotiques…
médecins, infirmières, kinés, assistantes sociales, porteurs de repas,
aides journalière,
entourage…
N. Anciaux – soutenance HDR
Sauvegarde
Boîte aux lettres
Synchronisation
33
Dossier complet (au chevet, en consultation)
Droits différenciés,
Restauration à partir d’une archive chiffrée
Synchronisé avec les chaines de traitement externes
Difficulté de convaincre les institutionnels
Solution DMSP : fonctionnement
PR SM
Application DMSP : conclusion et résultats
Usage sur le terrain de nos technologies
Moteur SGBDR embarqué
Nouveau modèle de contrôle d’accès orienté évènements (EBAC)
Pilote JDBC embarqué implanté en Javacard
Algorithme de synchronisation asynchrone
Expérimentation terrain: 40 patients, 80 professionnels
Audit du DMSP (ARS & CG78) en vue d’une généralisation
34
2008
2015
Application DMSP/EBAC: IJTA’08, CBMS’08,
IJHDRI’09, Book Chapter 09, Cahiers du CRID 09
Démos: Javaone’09, RII’11, RII’14, FeS’13…
Audition de SMIS à l’Assemblée
Expérimentation terrain
PR SM
Au-delà de DMSP
Une Plateforme pour le Web Personnel Sécurisé
Conception d’un nouveau dispositif matériel
Carte à puce
Microcontrôleur
Carte microSD
Lecteur d’empreinte
Microphone
Interface USB et Bluetooth
Fabrication par n’importe
quel assembleur
Intégration de nos algorithmes
(en cours)
35
SD card
Bluetooth
Fingerprint
reader
Smartcard
(gestion de
données)
(secrets)
(données)
MCU
USB
PR SM
Dynamique de dissémination autour de la plateforme
Logique open source et open hardware
Dissémination de la plateforme auprès des étudiants
Par l’enseignement : plateforme ENSIIE, INSA Lyon, INSA Bourges
Au travers du FabLab de l’Université de Versailles
Ouverture vers d’autres communautés scientifiques
Dans l’ISN (économistes, juristes) et le PEPS ‘PAIP’
Ouverture vers des applications sociétales
Avec le LIRIMA : solution médicale/édu. sans infrastructure
Avec le RITM (et SILLAGE) : plateforme pour l’eco. expé. (& MOOC)
Avec la FING et CozyCloud : "Blue Button" à la Française
Collaboration avec des acteurs industriels du Web Personnel
Collaboration avec CozyCloud : coupler CozyCloud et PlugDB
36
PR SM
Conclusion générale
Bilan scientifique
Architectures: Serveur personnel, Cellules de confiance, Folk-IS
Algorithmes de gestion de données embarquées : stockage,
indexation, interrogation, atomicité, croisement de données
publiques/privées
Modèles: contrôle d’accès basé événements, dégradation progressive
de données, exposition minimum
Prototypes et expérimentations
Travaux futurs auxquels j’aimerais me consacrer
Sécuriser de nouveaux modèles de données / contrôles d’accès
Contrôle d’usage : sécuriser des traitements de données complexes
Gestion de données sans infrastructure
37
PR SM
Sécuriser de nouveaux modèles de données et de
contrôles d’accès Transposition en embarqué de modèles orientés documents
Recherche sur le contenu et contrôle d’accès basé tags/attributs (S. Lallali)
Généralisation des principes de design à d’autres structures d’indexation
Motivation
User Desktop pour le Web Personnel Sécurisé (moteur de recherche)
Droits des applications fonction de tags apposés sur les fichiers
Etat de l’art
RI classiques: index inversé arborescent, calcul tf-idf avec beaucoup de RAM
RI embarqués: pas de passage à l’échelle, ni suppression, ni contrôles d’accès
Microsearch [TECS’10], capteurs photos [SenSys08], MAX [TOSN’08], Snoogle [TPDS10]…
Approche
(1) index inversé composé de partitions séquentielles (jamais modifiées)
(2) Coût de la recherche sur N partitions ~ coût sur une structure optimale
(3) fusions successives des partitions sans générer d’écriture aléatoire
38
PR SM
Contrôle d’usage
Traitement de données complexes : étendre la sphère de sécurité
Brassent de grands volumes de données, mais ne peuvent être embarquées
Ex. calculs de profils, recommandations, désagrégation de séries temporelles
Contrôle d’usage : limiter la fuite d’information d’un traitement de données externe
En collaboration avec P. Bonnet
Challenge
Limiter les effets de bord d’un traitement externe (code potentiellement corrompu)
Scénario d’application : désagrégation de trace énergétique
Solution Cloud : transmission de toutes les données à un service de désagrégation
Sécurisation limitée à certaines primitives (facturation, statistiques anonymes)
Approche
L’association d’un environnement d’exécution sécurisé
avec un environnement non sécurisé mais isolé (sandboxing)
et déposable (sans mémoire d’une exécution à l’autre)
Et des techniques de vérification du résultat avant déclassification
39
PR SM
Gestion de données sans infrastructure : Folk-IS
Services orientés données à bas coût dans les pays les moins avancés
Facteur de développement économique, dans l’éducation, la santé, la finance, etc.
Solutions génériques « lourdes »: Loon (Google), Internet.org (Facebook)
Solutions ad-hoc légères (échanges de SMS) : chaîne du froid, agriculture, e-admin
Un serveur personnel sécurisé sans écran ni clavier
Des terminaux partagés sur lesquels tournent les applications
De nombreux challenges BD liés au manque d’infrastructure
Ex. Requêtes globales sans infrastructures
Techniques BD distribuées ou P2P? Connaissance de la localisation des nœuds
Notre approche Hypothèse de monde ouvert: admettre la possibilité de résultats approchés,
terminer les requêtes
Identifier les sources adaptées sans surcharger le réseau (conditions spatiales)
Router les requêtes et les réponses (protocoles géographiques, profile de mobilité,
principe de « l’ étranger familier »)…
40