Java,	  le	  maillon	  faible	  du	  vote	  par	  internet.	  	  Par	  Roméo	  Gallabert,	  ingénieur	  systèmes	  et	  ré...
Comme	  le	  chiffrement	  asymétrique	  nécessite	  plus	  de	  puissance	  CPUxii,	  il	  peut	  s’avérer	  très	  lent....
dont	  le	  pirate	  aurait	  pris	  le	  contrôle,	  le	  système	  de	  vote	  n’avait	  donc	  aucun	  moyen	  de	  dét...
Parce	  que	  la	  clef	  publique	  de	  chiffrement	  est	  connue	  sur	  le	  poste	  du	  votant,	  le	  pirate	  peu...
 	  D’autres	  failles	  sont	  donc	  introduites	  dans	  ce	  type	  de	  solution	  :	         -­‐      Les	  clefs	  ...
Dans	  un	  document	  nommé	  	  «	  Cyber-­‐conflits,	  quelques	  clés	  de	  compréhension»xxviii	  publié	  en	  2011...
 	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	  	   	  ...
Prochain SlideShare
Chargement dans…5
×

Java maillon faible du vote par internet

3 245 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
3 245
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Java maillon faible du vote par internet

  1. 1. Java,  le  maillon  faible  du  vote  par  internet.    Par  Roméo  Gallabert,  ingénieur  systèmes  et  réseaux.    rgallabert@gmail.com    La  France  est  un  pays  précurseur  dans  l’usage  du  vote  par  internet  pour  divers  types  d’élections  relevant  de  la  sphère  privée  et  publique  depuis  une  dizaine  d’années.  La  législation  française  a  permis  son  usage  pour  des  élections  politiques  pour  les  français  résidant  à  l’étranger  dès  2003,  pour  les  élections  professionnelles  dans  le  cadre  du  Code  du  Travail  dès  2004  ou  pour  les  votes  en  assemblées  générales  d’actionnaires  dans  le  cadre  du  Code  du  Commerce.    Ce  sont  donc  des  milliers  de  scrutins  qui  sont  gérés  en  vote  par  internet  en  France  chaque  année  et  pour  lesquels  la  sincérité  du  scrutini  devrait  être  une  garantie  absolue.    Mais  lors  des  dernières  élections  législatives  de  juin  2012  où  le  vote  par  internet  était  possible  pour  les  français  de  l’étranger,  un  informaticien,  Laurent  Grégoire,  a  démontré  qu’il  était  très  simple  de  modifier  les  bulletins  de  vote  des  électeurs  à  leur  insu  par  une  simple  manipulation  d’une  applet  Java  sur  le  poste  du  votant.ii    Suite  à  ce  scrutin,  de  nombreux  recours  avaient  été  déposés  auprès  du  Conseil  Constitutionnel  qui  a  reconnu  l’existence  d’anomalies.iii  Le  détail  des  décisions  rendues  le  15  février  2013  est  assez  éloquent  sur  la  possibilité  de  bulletins  de  vote  corrompus  :  «  ..Considérant  que  la  circonstance,  à  la  supposer  établie,  quun  électeur  de  la  4ème  circonscription  est  parvenu  à  exprimer  par  voie  électronique,  au  second  tour  du  scrutin,  un  vote  en  faveur  dun  candidat  ne  figurant  pas  sur  la  liste  des  candidats  autorisés  à  se  maintenir  à  ce  tour  nest  pas  susceptible  davoir  altéré  la  sincérité  du  scrutin…………  il  résulte  de  linstruction,  en  particulier  du  procès-­‐verbal  du  bureau  du  vote  électronique,  que  le  dépouillement  automatique  des  suffrages  exprimés  dans  la  4ème  circonscription  a  été  initialement  interrompu  par  la  présence  dun  vote  ne  correspondant  pas  aux  paramètres  retenus  par  le  système….  »    Il  apparaît  donc  officiellement  que  des  bulletins  électroniques  ont  pu  être  corrompus  lors  d’une  élection  politique  en  France  et  la  démonstration  de  faisabilité  qui  en  avait  été  faite  par  Laurent  Grégoire  apparaît  encore  plus  d’actualité  depuis  quelques  mois  avec  les  cyber-­‐attaques  dont  ont  fait  l’objet  divers  sites  gouvernementauxiv  et  de  médias  ainsi  que  les  sociétés  Apple,  Microsoft,  Facebook  ou  encore  Twitter  qui  reconnaît  que  plus  de  250.000  comptes  pourraient  avoir  été  violés.v    L’ampleur  du  danger  est  telle  que  le  gouvernement  Américain  a  qualifié  dans  un  discours  de  Barak  Obama  de  cyber-­‐guerrevi  les  attaques  menées  par  les  pirates  exploitant  les  failles  de  Javavii  et  appelle  tous  les  utilisateurs  d’internet  à  restreindre  voire  supprimer  Java  de  leurs  ordinateurs.viii    Or  la  majorité  des  prestataires  de  vote  par  internet  en  France  imposent  l’usage  de  Java  pour  assurer  le  chiffrement  des  bulletins  de  vote  via  des  programmes  «  applets  »ix  ou  de  programmes  inspirés  du  langage  Java  appelés  «Javascript  »x  qui  seront  téléchargés  sur  le  poste  internet  du  votant.    Ces  programmes    utilisent  des  algorithmes  de  chiffrement  asymétrique  tel  que  RSA  ou  El  Gamalxi  impliquant  l’usage  combiné  d’une  clef  «  publique  »  et  d’une  clef  «  privée  »  correspondante.  Le  bulletin  de  vote  est  chiffré  par  la  clef  «  publique  »  et  ne  peut  être  déchiffré  que  par  la  clef  «  privée  »  conservée  par  les  membres  du  bureau  de  vote  ou  le  prestataire.  La  clef  «  publique  »  est  directement  envoyée  sur  tous  les  postes  des  votants  puisqu’elle  ne  peut  être  utilisée  pour  déchiffrer  un  bulletin  de  vote  chiffré  sans  la  clef  «  privée  »  assurant  ainsi  théoriquement  le  secret  du  vote….           1    
  2. 2. Comme  le  chiffrement  asymétrique  nécessite  plus  de  puissance  CPUxii,  il  peut  s’avérer  très  lent.    Pour  accélérer  ce  type  de  chiffrement,  il  est  normalement  fait  appel  à  une  «  applet  »  Java  qui  est  téléchargée  sur  le  poste  du  votant  pour  permettre  le  chiffrement  du  bulletin.      L’alternative  à  l’usage  d’une  «  applet  »  Java  est  l’usage  d’un  «  Javascript  »  sur  le  poste  du  votant,  mais  un  «  Javascript  »  sera  beaucoup  plus  lent  qu’une  «  applet  »  Java  à  effectuer  le  grand  nombre  de  calculs  que  nécessite  un  algorithme  de  chiffrement  asymétrique  et  aussi  beaucoup  plus  simple  à  pirater  via  un  «  malware  »xiii  ou  un  «  cheval  de  troie  ».xiv  De  plus,  il  s’installe  facilement  à  l’insu  du  votant  sur  son  poste  internet  via  le  chargement  de  la  page  web  du  bulletin  de  vote  et  contourne  ainsi  les  règles  de  sécurité  réseaux  qui  peuvent  imposer  les  gestionnaires  de  sécurité  informatique.    Quelque  soit  le  type  de  programme  utilisé  pour  le  chiffrement  du  bulletin,  «  applet  »  Java  ou  «  Javascript  »,  le  principal  problème  reste  que  le  chiffrement  et  la  transmission  du  bulletin  est  effectué  uniquement  sur  le  poste  du  votant  qui  est  le  «  maillon  faible  »  de  la  chaîne  de  traitement  du  vote  car  impossible  à  sécuriser  par  les  ingénieurs  en  sécurité  informatique  du  prestataire  de  vote.    De  plus  comme  le  bulletin  est  envoyé  chiffré  directement  du  poste  du  votant  jusqu’à  la  base  de  données  du  prestataire  hébergeant  l’urne  virtuelle  sur  ses  serveurs,  aucun  contrôle  d’intégrité  des  données  et  donc  de  sincérité  du  vote  ne  peut  être  effectué  en  dehors  du  poste  du  votant,  ce  qui  ouvre  un  certain  nombre  d’actes  de  piratage  possibles  :    Attaque  1  :  modification  de  l’applet  Java.      Cette  attaque  a  été  très  bien  démontrée  par  Laurent  Grégoire  qui  a  été  capable  de  prendre  la  main  sur  l’applet  «  java  »,  de  décompiler  le  code  et  de  modifier  le  programme  pour  qu’il  puisse  voter  à  l’insu  du  votant  pour  un  autre  candidat.    Le  piratage  du  bulletin  était  simple  à  réaliser  et  le  prestataire  du  Ministère  des  Affaires  Etrangèresxv  n’avait  aucun  moyen  de  détecter  la  fraude,  par  ailleurs  le  bulletin  n’étant  pas  corrompu  et  juste  modifié  il  aurait  été  déchiffré  sans  erreur  par  le  système.  L’installation  d’un  virus  de  type  «  cheval  de  troie  »  spécifique  sur  divers  postes  de  votants  aurait  ainsi  permis  de  modifier  à  l’insu  des  nombreux  votants  leurs  votes  sans  qu’ils  s’en  aperçoivent.    Attaque  2  :  interception  et  manipulation  d’un  composant  html  de  la  page  Web  du  bulletin  de  vote    Nous  montrons  ci-­‐après  une  partie  du  programme  («  snippet  »)xvi  utilisée  pour  le  vote  des  élections  des  représentants  aux  TPExvii  organisé  par  le  Ministère  du  Travail  en  décembre  2012.     <input  type="hidden"  name="maxSelection"  value="1"  id="maxSelection">   <input  type="hidden"  name="minSelection"  value="1"  id="minSelection">      Le  code  ci-­‐dessus  gère  les  variables  de  contrôle  du  nombre  autorisé  de  listes  de  candidats  que  l’on  peut  voter  sur  un  bulletin.    La  règle  de  vote  était  que  l’on  pouvait  soit  choisir  une  liste  soit  voter  «  blanc  »,  le  votant  devait  sélectionner  un  minimum  de  «  1  »  choix  et  un  maximum  de  «  1  »  choix  parmi  les  listes  proposées.    Il  était  donc  très  simple  d’intercepter  l’exécution  de  la  page  Web  sur  le  poste  du  votant,  de  lire  le  code  et  de  changer  le  contenu,  la  plupart  des  navigateurs  offrent  cette  possibilité  aux  développeurs  lorsqu’ils  développent  des  pages  web.    On  pouvait  donc  modifier  la  variable  «  maxSelection  »  à  «  2  »  ou  plus,  ce  qui  permettait  au  programme  de  choisir  plusieurs  listes  de  candidats  à  l’insu  du  votant,  de  chiffrer  le  bulletin  puis  de  l’envoyer  à  l’urne  virtuelle.    Comme  le  seul  contrôle  effectué  se  faisait  sur  le  navigateur  du  votant     2    
  3. 3. dont  le  pirate  aurait  pris  le  contrôle,  le  système  de  vote  n’avait  donc  aucun  moyen  de  détecter  qu’un  bulletin  non  conforme  ait  été  reçu  dans  l’urne.  Le  résultat  aurait  été  alors  un  écart  entre  le  nombre  de  vote  exprimés  pour  des  listes  et  le  nombre  de  votants…    Attaque  3  :  interception  de  l’exécution  du  vote  entre  la  page  web  affichant  le  bulletin  de  vote  et  la  page  de  confirmation  du  vote.    Ceci  est  une  autre  partie  de  l’applet  Java  utilisée  pour  le  vote  des  élections  des  représentants  aux  TPE  de  décembre  2012.         <script>       function  voter()  {       $("#btnVoter").attr("disabled",  "disabled");     $("#btnVoter").addClass("disabled");       document.getElementById(applet).setButtonClick();       }     </script>                     <applet  i d=applet  code=CypherApplet.class  archive=../applet/SVoteApplet.jar;jsessionid=nnnnnnnnnnn  width=0  height=0>                     <param  name="codebase_lookup"  value="false"  />                     <param  name="MAYSCRIPT"  value="yes"  />                     <param  name="scriptable"  value="true"  />                     <param  name="sessionId"  value="nnnnnnnnnnn"  />                   <param  name="cache_option"  value="no"  />     </applet>                       <input  type="button"  id="btnVoter"  value="VOTER"  class="button  disabled"  onclick="voter()"  disabled="disabled">        La  dernière  ligne  du  programme  ci-­‐dessus    commande  au  navigateur  l’affichage  du  bouton  «  VOTER  »  sur  la  page  Web  du  bulletin  de  vote.    Lorsque  le  votant  a  fait  son  choix  sur  le  bulletin  puis  l’a  vérifié  sur  la  page  dite  de  confirmation,  il  devait  alors  cliquer  sur  ce  bouton.    Cette  action  du  programme  est  effectuée  lorsque  le  clic  est  effectué  (évènement  «  onclick  »)  appelant  la  fonction  Javascript  ‘voter’.  Ce  code  est  visible  dans  les  7  premières  lignes  du  programme.  L’affichage  du  bouton  «  VOTER  »  est  en  fait  simplement  caché  sur  la  page  du  bulletin  (‘disabled’)  pour  ensuite  lancer  l’applet  Java,  tel  que  défini  au  milieu  du  programme  ci-­‐dessus.    En  prenant  le  contrôle  du  navigateur,  un  pirate  peut  alors  ajouter  un  point  de  contrôle  sur  la  fonction  ‘voter’,  modifier  le  choix  du  bulletin  et  ensuite  lancer  l’applet  Java  normalement  à  l’insu  du  votant.  Ainsi  même  si  le  votant  a  cru  vérifier  son  choix  sur  sa  page  de  validation,  son  vote  a  pu  être  modifié  sans  qu’il  s’en  aperçoive  après  que  le  votant  ait  déjà  confirmé  son  vote.  Le  bulletin  peut  être  ainsi  transmis  chiffré  à  l’urne  virtuelle  avec  un  autre  choix  que  celui  effectué  par  le  votant.    Attaque  4  :  rétro-­‐ingénierie  (reverse  engineering)  du  protocole  de  conception  du  bulletin  de  vote  permettant  de  créer  sa  propre  version  de  l’applet  de  chiffrement.      Cela  consiste  à  étudier  le  programme  pour  en  déterminer  le  fonctionnement  interne.    Comme  le  code  du  programme  («  applet  »  java  ou  «  javascript  »)  est  disponible  sur  le  poste  du  votant  soit  en  clair  soit  par  décompilation  de  l’applet  Java,  il  est  possible  à  un  pirate  de  déterminer  exactement  comment  est  construit  le  bulletin  avant  chiffrement.     3    
  4. 4. Parce  que  la  clef  publique  de  chiffrement  est  connue  sur  le  poste  du  votant,  le  pirate  peut  créer  une  nouvelle  applet  qui  votera  pour  le  candidat  voulu  et  effectuera  le  chiffrement  d’un  bulletin  conforme  pour  le  système  de  vote  qui  pourra  ensuite  être  déchiffré  normalement.  Le  pirate  peut  donc  aisément  substituer  son  «  applet  »  («  malware  »)  en  lieu  et  place  de  l’applet  du  prestataire  et  ainsi  faire  voter  le  navigateur  du  votant  comme  il  le  souhaite  tout  en  faisant  croire  au  votant  que  c’est  son  choix  à  lui  qui  aurait  été  effectué.    La  rétro-­‐ingénierie  de  l’applet  n’est  d’ailleurs  pas  toujours  indispensable  car  la  plupart  des  prestataires  de  vote  par  internet  en  France  utilisent  le  même  programme  de  chiffrement  asymétrique  développé  en  «  javascript  »par  un  chercheur,  Tom  Wu,  de  l’Université  de  Stanfordxviii  aux  USA  en  2005.    Ainsi  à  la  lecture  du  programme  dans  un  bulletin  de  vote  utilisé  pour  une  élection  professionnelle  organisée  chez  ORANGE  en  février  2013xix,  on  peut  constater  des  failles  supplémentaires.    Le  bulletin  de  vote  web  est  chiffré  par  le  programme  de  Tom  Wuxx,  le  système  va  ensuite  échanger  en  clair  avec  le  serveur  le  choix  du  votant  avant  son  chiffrement  sur  le  poste  du  votant.    On  peut  ainsi  lire  dans  le  «  snippet  »  de  la  page  du  bulletin  de  vote  que  le  choix  pour  une  liste  est  affecté  à  un  numéro  (par  exemple,  ici  la  valeur  15  pour  le  choix  de  la  liste  CFE-­‐CGC/UNSA)      Cette  valeur  est  envoyée  en  clair  au  serveur  via  le  protocole  SSLxxi  en  utilisant  une  commande  «  http  POST  »xxii,  le  votant  restant  identifié  lors  de  l’échange  avec  le  serveur  par  un  cookie  de  session  temporaire  JSESSIONIDxxiii      Le  serveur  répond  en  affichant  une  page  web  de  confirmation  montrant  le  vote  pour  la  liste  CFE-­‐CGC/UNSA  à  l’électeur  avec  la  variable  ‘15’.      Lorsque  le  bouton  “VOTE”  est  cliqué  par  le  votant,  la  page  du  bulletin  est  alors  chiffrée  avec  le  programme  Javascript  en  remplaçant  le  texte  du  bulletin  par  une  version  chiffrée  RSA  en  base  64xxiv  puis  envoyé  à  l’urne  virtuelle  via  une  commande  http  post.         4    
  5. 5.    D’autres  failles  sont  donc  introduites  dans  ce  type  de  solution  :   -­‐ Les  clefs  de  choix  d’une  liste  ou  d’un  candidat  sont  aisément  compréhensibles.    En   interceptant  la  page  html  de  confirmation  du  vote,  un  pirate  peut  simplement  remplacer  une   valeur  de  clef  par  une  autre  sans  que  le  votant  s’aperçoive  de  la  modification.   -­‐ Comme  le  format  du  bulletin  est  connu,  les  valeurs  de  chaque  choix  (liste  ou  candidat)  sont   compréhensibles,  ainsi  qu’est  connue  la  clef  «  publique  »  de  chiffrement  transmise  avec  le   bulletin  par  le  serveur.  Un  pirate  peut  donc  sans  difficulté  créer  un  bulletin  chiffré  avec  son   propre  choix  et  le  faire  envoyer  à  l’urne  virtuelle  via  un  «  http  post  »  à  l’insu  du  votant.      Attaque  5  :  rendre  le  bulletin  illisible.      Une  autre  attaque  très  simple  par  rétro-­‐ingénierie  de  l’applet  se  fera  en  déterminant  comment  le  protocole  réseau  et  le  format  du  message  est  construit  entre  l’applet  et  le  serveur  du  prestataire  lorsque  le  bulletin  chiffré  est  retransmis  vers  le  serveur.    Le  pirate  peut  alors  écrire  un  «  malware  »  qui  va  examiner  cet  échange  puis  simplement  modifier  quelques  octets  au  hasard  du  bulletin  chiffré.  Ainsi  le  bulletin  ne  sera  plus  déchiffrable.    De  cette  manière,  un  bulletin  qui  était  normalement  conforme  pourra  être  transformé  en  bulletin  illisible  donc  nul.      Si  le  pirate  arrive  à  distribuer  son  malware  sur  un  certain  nombre  de  poste  de  votants,  par  exemple  via  un  site  web  de  campagne  d’un  candidat  ou  via  un  réseau  social  de  supporters  d’un  candidat  ou  encore  via  la  distribution  d’emails  de  campagne  électorale  du  candidat,  il  pourrait  «  nullifier  »  systématiquement  tous  les  bulletins  émanant  des  postes  des  votants  qui  se  seraient  intéressés  à  ce  candidat  et  qui  auraient  à  leur  insu  été  infectés  par  le  malware.    Cette  possibilité  de  détournement  en  masse  d’applets  a  été  démontrée  lors  des  attaques  dont  ont  fait  l’objet  Apple,  Microsoft,  Facebook  ou  encore  Twitter  ces  deux  derniers  mois.      Daprès  le  site  Arstechnicaxxv,  qui  reprend  une  hypothèse  précédemment  défendue  par  RSA  Securityxxvi,  les  auteurs  de  lattaque  auraient  en  réalité  commencé  par  infecter  un  forum  Web  fréquenté  par  des  développeurs  travaillant  sous  Mac  (iphonedevdsk.com,  quil  vaut  mieux  donc  ne  pas  visiter),  selon  la  tactique  dite  du  «  waterhole  ».xxvii    Cette  tactique  consiste  donc  à  plutôt  que  de  sen  prendre  directement  à  une  cible  donnée,  lidée  est  de  distribuer  linfection  à  partir  dun  point  dintérêt  susceptible  dattirer  les  publics  chez  qui  lon  souhaite  sintroduire.    Dans  le  cadre  d’élections  politiques,  un  site  web  de  campagne  serait  donc  une  cible  idéale  pour  distribuer  le  «  malware  ».      Dans  le  cadre  d’élections  professionnelles  où  le  service  informatique  de  la  société  est  en  charge  de  la  gestion  des  postes  de  travail  de  tous  les  salariés  et  donc  de  leur  sécurité,  on  pourrait  imaginer  aussi  qu’un  informaticien  assurant  la  gestion  des  versions  de  logiciels  par  exemple  pourrait  introduire  ce  type  «  malware  »  et  ainsi  faire  voter  pour  les  candidats  de  son  choix  dont  il  pourrait  d’ailleurs  faire  partie…..         5    
  6. 6. Dans  un  document  nommé    «  Cyber-­‐conflits,  quelques  clés  de  compréhension»xxviii  publié  en  2011  par  l’agence  gouvernementale  française  de  sécurité  en  informatique  l’ANSSIxxix,  il  est  rappelé    l’évolution  exponentielle  du  nombre  de  «  malware  »  apparus  ces  dernières  années…       Source  :  “The  Cyber-­‐Crime  Black-­‐Market:  Uncovered”,  Panda  Security  Press      Le  danger  est  donc  bien  réel,    et  vouloir  faire  reposer  la  sécurité  du  vote  par  internet  sur  le  seul  poste  internet  du  votant,  qu’il  soit  à  usage  privé,  public  ou  professionnel,  que  ce  soit  par  l’usage  d’applet  Java,  de  Javascript  ou  autres  «  plug-­‐in  »,  est  donc  à  proscrire.    Lors  du  Symposium  sur  la  sécurité  des  technologies  de  linformation  et  des  communications  (SSTIC)  de  2012,  un  ingénieur  de  la  SERMAxxx  ,  société  agréée  Centre  d’Évaluation  de  la  Sécurité  des  Technologies  de  l’Informationxxxi,  a  démontré  quune  vulnérabilité  dapparence  anodine  permettait  de  compromettre  intégralement  une  application  bancaire  utilisant  des  cartes  à  puce  sur  une  plateforme  Java  Cardxxxii  pourtant  reconnue  particulièrement  sécurisée  par  le  monde  bancaire.  Il  confirmait  dans  ses  conclusions  la  nécessité  faite  aux  banques  de  privilégier  des  applications  permettant  de  vérifier  l’intégrité  des  échanges  entre  la  carte  bancaire  de  l’utilisateur  et  le  serveur  central  et  d’éviter  l’usage  de  Java  embarqué.    Ce  qui  est  applicable  au  monde  de  la  banque  devrait  donc  être  entendu  par  les  acteurs  du  vote  électronique  afin  d’éviter  la  liste  des  risques  ici  cités  et  ainsi  mettre  en  doute  la  sincérité  du  vote  sur  la  plupart  des  scrutins  organisés  par  internet  en  France.    Il  ne  s’agit  donc  pas  dans  cet  article  de  rejeter  l’usage  d’internet  pour  diverses  pratiques  démocratiques  comme  les  élections,  les  référendums  ou  pétitions  mais  bien  de  garder  les  yeux  ouverts  sur  les  réalités  techniques  qu’il  convient  de  prendre  en  compte  pour  offrir  un  système  de  vote  qui  offre  toutes  les  garanties  de  sincérité  du  scrutin  et  de  secret  du  vote  qui  s’imposent  à  toute  démocratie  moderne.                                                                                                                          i  http://www.conseil-­‐constitutionnel.fr/conseil-­‐constitutionnel/francais/cahiers-­‐du-­‐conseil/cahier-­‐n-­‐13/la-­‐notion-­‐de-­‐sincerite-­‐du-­‐scrutin.52035.html  ii  http://www.scribd.com/doc/94990325/Comment-­‐mon-­‐ordinateur-­‐a-­‐vote-­‐a-­‐ma-­‐place-­‐et-­‐a-­‐mon-­‐insu     6    
  7. 7.                                                                                                                                                                                                                                                                                                                                                                                    iii  http://www.conseil-­‐constitutionnel.fr/conseil-­‐constitutionnel/francais/les-­‐decisions/acces-­‐par-­‐date/decisions-­‐depuis-­‐1959/2013/2012-­‐4597/4626-­‐an/decision-­‐n-­‐2012-­‐4597-­‐4626-­‐an-­‐du-­‐15-­‐fevrier-­‐2013.136040.html  iv  http://venturebeat.com/2013/01/11/homeland-­‐security-­‐java/  v  http://blog.twitter.com/2013/02/keeping-­‐our-­‐users-­‐secure.html  vi  http://www.courrierinternational.com/article/2013/02/05/barack-­‐obama-­‐commandant-­‐en-­‐chef-­‐de-­‐la-­‐cyberguerre  vii  http://www.us-­‐cert.gov/ncas/alerts/ta13-­‐010a  viii  http://www.kb.cert.org/vuls/id/625617  ix  http://fr.wikipedia.org/wiki/Applet_Java  x  http://fr.wikipedia.org/wiki/JavaScript  xi  http://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique  xii  http://fr.wikipedia.org/wiki/CPU  xiii  http://fr.wikipedia.org/wiki/Logiciel_malveillant  xiv  http://fr.wikipedia.org/wiki/Cheval_de_Troie_(informatique)  xv  http://www.diplomatie.gouv.fr/fr/vivre-­‐a-­‐l-­‐etranger/elections-­‐2012-­‐votez-­‐a-­‐l-­‐etranger/  xvi  http://fr.wikipedia.org/wiki/Snippet  xvii  http://www.electiontpe.travail.gouv.fr/  xviii  http://www-­‐cs-­‐students.stanford.edu/~tjw/jsbn/LICENSE  xix  https://www.votes.voxaly.com/electionsccp-­‐communication/  xx  http://www-­‐cs-­‐students.stanford.edu/~tjw/jsbn  xxi  http://fr.wikipedia.org/wiki/Transport_Layer_Security  xxii  http://en.wikipedia.org/wiki/POST_(HTTP)  xxiii  http://en.wikipedia.org/wiki/Session_ID  xxiv  http://en.wikipedia.org/wiki/Base_64  xxv  http://arstechnica.com/security/2013/02/web-­‐forum-­‐for-­‐iphone-­‐developers-­‐hosted-­‐malware-­‐that-­‐hacked-­‐facebook/  xxvi  http://fr.wikipedia.org/wiki/RSA_Security  xxvii  http://fr.slideshare.net/symantec/waterhole-­‐attack  xxviii  http://www.ssi.gouv.fr/fr/anssi/publications/autres-­‐publications-­‐233/cyber-­‐conflits-­‐quelques-­‐cles-­‐de-­‐comprehension.html  xxix  http://www.ssi.gouv.fr/  xxx  https://www.sstic.org/2012/presentation/compromission_application_bancaire_javacard/  xxxi  http://www.ssi.gouv.fr/fr/certification-­‐qualification/cesti/presentation-­‐6.html  xxxii  http://fr.wikipedia.org/wiki/Java_Card     7    

×