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,
qu'un
électeur
de
la
4ème
circonscription
est
parvenu
à
exprimer
par
voie
électronique,
au
second
tour
du
scrutin,
un
vote
en
faveur
d'un
candidat
ne
figurant
pas
sur
la
liste
des
candidats
autorisés
à
se
maintenir
à
ce
tour
n'est
pas
susceptible
d'avoir
altéré
la
sincérité
du
scrutin…………
il
résulte
de
l'instruction,
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
d'un
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. 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. 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. 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.
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.
D'après
le
site
Arstechnicaxxv,
qui
reprend
une
hypothèse
précédemment
défendue
par
RSA
Securityxxvi,
les
auteurs
de
l'attaque
auraient
en
réalité
commencé
par
infecter
un
forum
Web
fréquenté
par
des
développeurs
travaillant
sous
Mac
(iphonedevdsk.com,
qu'il
vaut
mieux
donc
ne
pas
visiter),
selon
la
tactique
dite
du
«
waterhole
».xxvii
Cette
tactique
consiste
donc
à
plutôt
que
de
s'en
prendre
directement
à
une
cible
donnée,
l'idée
est
de
distribuer
l'infection
à
partir
d'un
point
d'intérêt
susceptible
d'attirer
les
publics
chez
qui
l'on
souhaite
s'introduire.
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. 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
l'information
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é
qu'une
vulnérabilité
d'apparence
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.
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