e--commerce securise

haltingbarberInternet and Web Development

Aug 15, 2012 (4 years and 10 months ago)

566 views

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

1
/
36

Romain C
OMBET

J
ean
-
Luc N
ALLET


DESS IIR Réseaux










Architecture &

Solutions sécurisées

pour l’e
-
commerce























UFR Informatique

Université Claude Bernard Lyon I

Janvier 2002

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

2
/
36



Introduction

................................
................................
................................
................................

3

I Les quatre grands principes du e
-
commerce

................................
................................
............

4

I.1

L
E CHIFFREMENT

................................
................................
................................
................

4

I.2

DES

(D
ATA
E
NCRYPTION
S
TANDARD
)

................................
................................
...............

5

I.3

L
ES ALGORITHMES A CLE

PUBLIQUE
.

................................
................................
..................

7

I.4

L’
ALGORITHME
RSA
................................
................................
................................
..........

8

I.5

A
UTHENTICITE ET TIERS

DE CONFIANCE

................................
................................
.............

9

II Juridiction

................................
................................
................................
.............................

10

III Les transactions sécurisées

................................
................................
................................
..

11

III.1

L
E PROTOCOLE
SSL

(S
ECURE
S
OCKETS
L
AYER
)

................................
...........................

11

III.1.1 Historique

................................
................................
................................
..............

11

III.1.2 Fonctionnement

................................
................................
................................
.....

11

III.1.3 Le chiffrement utilisé avec

SSL

................................
................................
.............

12

III.1.4 Le protocole handshake

................................
................................
........................

13

III.1.5 L’authentification du serveur (par le client)

................................
.........................

17

III.1.6 L’authentification du client (par le serveur)

................................
.........................

18

III.1.7 Faiblesses

................................
................................
................................
..............

20

III.2

L
E PROTOCOLE
SET

................................
................................
................................
......

21

III.2.1 Historique

:

................................
................................
................................
...........

21

II.2.2 Scénario

................................
................................
................................
..................

21

I
II.3

O
DYSSEO

................................
................................
................................
.......................

23

C
ONCLUSION

:

................................
................................
................................
.......................

23

IV Solutions et architectures commerciales

................................
................................
.............

23

IV.1L
ES OFFRES COMPLETES

................................
................................
................................
.

23

IV.2

L
ES SOLUTIONS

LOGICIELLES

................................
................................
........................

24

IV.3

L’
OFFRE COMMERCIALE
C
-
SET

................................
................................
....................

25

IV.4

L
ES ORGANISMES CERTIF
ICATEURS

................................
................................
...............

25

IV.5

L’
AUTHENTIFICATION UNI
QUE

................................
................................
......................

26

V
Annexe

................................
................................
................................
................................
..

27

G
LOSSAIRE

................................
................................
................................
............................

27

B
IBLIOGRAPHIE

................................
................................
................................
.....................

29

D
OCUMENTS

................................
................................
................................
..........................

30


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

3
/
36


Introduction


Qu’est
-
ce que le commerce

? C’est une notion aussi an
cienne que notre civilisation
(quelques millénaires). Elle consiste en une transaction (on entend par
-
là, échange de produit)
entre deux ou plusieurs parties.

Les deux parties contractantes se mettent d’accord sur le produit à acheter et son prix.
Selon le
s cas, ils définissent également la quantité à fournir, le délai de fabrication ou de mise
à disposition du produit, la qualité du produit, … Une fois cet accord établi, les deux parties
procèdent à l’échange proprement, dans le respect des conditions cont
ractées.

Le commerce est un acte anodin que nous exécutons de nombreuses fois par jour.
C’est aussi un acte juridiquement très encadré, et les lois qui le régissent dépendent de chaque
état.

Les deux parties peuvent conclure une transaction sans jamais se
rencontrer. La
transaction ne peut plus être faite de manière orale, elle est alors rédigée sur papier, et la
signature de chacune des parties les engage juridiquement à respecter le contrat alors établi.


Toutes ces conditions propres à chaque transactio
n doivent pouvoir être applicables
sur internet.


Qu’est
-
ce que le
e
-
commerce

? Le e
-
commerce ou commerce électronique est un
ensemble d’opérations commerciales effectuées par des personnes et des organisations, sans
document papier, à l’aide d’ordinateur
s et de réseaux de télécommunications privés ou
publics. (source

: tcpip
-
consultant.com/e
-
commerce.html).

L’étude réalisée par le Credoc et le cabinet Raffour Interactif
1

montre qu’en France, le
e
-
commerce ne représente que 0,05% du chiffre d’affaire des
ventes de détails, ce qui
équivaut à peine à 600 millions d’Euro. Mais si on ajoute que les ventes réalisées par le
Minitel sont sept fois plus importantes, l’avenir du e
-
commerce est très encourageant. Quant
aux entreprises, l’étude menée par Andersen Con
sulting
2

auprès de dirigeants européens et
américains fait ressortir que 97% des entreprises utilisent l’e
-
commerce et près de 80% ont
mis au point des projets destinés à exploiter le commerce électronique.

Dans le commerce traditionnel, de nombreuses tra
nsactions doivent rester secrètes afin
de ne pas informer la concurrence de sa stratégie marketing. Avec le e
-
commerce,
l’information doit également rester confidentielle. La
confidentialité

rend compte du fait que
seuls les utilisateurs habilités doivent
pouvoir prendre connaissance de l’information. Il faut
encore veiller à ce qu’aucun intrus ne vienne violer l’intégrité des informations transmises. Le

contrôle d’intégrité

est le moyen de s’assurer que le message que l’on reçoit est bien celui qui
a été e
nvoyé et qu’il n’a donc pas été altéré en cours de route. Comment avoir la certitude que
l’entité avec laquelle on dialogue est bien celle que l’on croit

? L’
authentification

permet de
reconnaître avec certitude l’entité avec laquelle on dialogue. Comment
prouver qu’un client a
bien passé électroniquement une commande de 10 millions de scoubidous à 89 centimes alors
qu’il prétend que le prix était de 69 centimes ? La
non
-
répudiation

concerne donc les
signatures, elle permet de garantir que le contrat de dép
art n’a pas été modifié et accepté par
chacune des parties.




1

Etude réalisée conjointement par le Credoc (centre de recherche pour l’étude et l’observation des conditions de
la vie) et le Cabinet Raffour
-
Interactif en septembre 2000 auprès de 1500 internautes. (source

:
http://www.medcost.fr/html/chiffres_sante/dossier_ch/ch_241100.htm
)

2

Enquête menée entre mai et juillet 2000 par Andersen Consulting auprès de 648 personnes (610 entretiens
téléphoniques et
38entretiens plus approfondis), dirigeants d’entreprises en Europe, aux Etats
-
Unis, et en Afrique
du Sud. (source

:
http://www.medcost.fr/html/chiffres_sante/dossier_ch
/ch_280900.htm
)

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

4
/
36

Afin de respecter ces quatre principes de bases du e
-
commerce (confidentialité,
authentification, intégrité et non
-
répudiation), de nombreuses solutions sont apportées aussi
bien par de grandes f
irmes, regroupées sous forme de consortium, que par de petites sociétés.
Le choix de ces
solutions
, qu’elles soient logicielles ou
architectures

matérielles, se font en
fonction du degré de sécurité qu’on veut accorder aux transactions. Nous nous efforcero
ns de
vous présenter et comparer les principales solutions présentées sur le marché actuel.



I Les quatre grands principes du e
-
commerce


Les quatre grands principes du e
-
commerce

sont la
confidentialité
, le
contrôle

d’intégrité
,
l’authentification

et la

non
-
répudiation
. La solution pour rendre le e
-
commerce
possible est le chiffrement ou cryptage. En effet une fois les données cryptées il est difficile
pour un étranger de comprendre le message codé. Nous allons donc vous décomposer la
technique de chiffr
ement.



I.1 Le chiffrement

Le chiffrement est un procédé très ancien. César utilisait déjà ce principe pour envoyer
des messages d’un camp à l’autre sans que les ennemis qui purent intercepter le message, ne
le comprennent. Une des méthodes utilisées par
César était la translation

: cela consiste en
décaler les lettres de x valeurs. Prenons un exemple de décalage de 3 lettres. Le A devient D,
le B devient E, le C devient F et ainsi de suite.

Ainsi "DOHD MDFWD HVW" est le cryptage par translation de 3 de l
a phrase "Alea
jacta est".


Le principe du chiffrement mathématique

: Alice souhaite envoyer un message à Bob
à travers un canal non sécurisé. Oscar, qui écoute secrètement le canal de transmission, ne
doit pas pouvoir comprendre le message.




A l’aide
d’une fonction mathématique de chiffrement, le message x est codé en une
suite de caractères y inintelligible appelé cryptogramme. Cette fonction mathématique est
appelée Clé de Cryptage. Le seul moyen de décrypter le cryptogramme est d’avoir la clé.

Atte
ntion, le chiffrement ne signifie pas qu’on travaille avec des chiffres, mais avec
des symboles.


Le premier mécanisme que nous allons expliquer est la clé symétrique, qui s’oppose à
la clé asymétrique (la clé qui déchiffre est différente de la clé qui ch
iffre).


La clé symétrique ou clé secrète


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

5
/
36

La clé symétrique ou clé secrète est qualifiée ainsi, car c’est la même clé qui déchiffre
que celle qui chiffre, et que la clé est connue à l’avance, gardée secrète et jamais transmise
directement sur le réseau.
Mathématiquement, cela signifie que si x est le message en clair, C
la Clé et y le message codé, on a alors

:


C (x) = y

pour l’étape du chiffrement, et

C (y) = x

pour le déchiffrement.


Comme nous l’avons expliqué plus haut, il est possible de faire un
e translation de
chaque caractère sur un alphabet tout entier.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

N X R J I T P V O D Q A S K M H B L Y C U D G Z E F


Ce procédé de chiffrement est facile à mettre œuvre par une architecture sim
ple de
circuits imprimés comme les Boîtes P (composant électronique opérant les
P
ermutations) et
les Boîtes S(composant électronique opérant les
S
ubstitutions).












Boîte P (P
-
box)


Boîte S (S
-
box
)



I.2 DES (Data Encryption Standard)


Le DES (Data Encryption Standard) développé en 1977 par IBM, est l’algorithme à
clé secrète le plus utilisé au monde. Il utilise les circuits Boîte P et boîte S. Son principe de
fonctionnement est le suivant

: des bl
ocs de texte clair en entrée sont chiffrés par une suite
d’itérations paramétrées qui produisent en sortie des blocs chiffrés de 64 bits.

La faille de ce système est que chaque fois qu’un bloc de 64 bits arrive en entrée, c’est
un même bloc de 64 bits qui

est récupéré en sortie. Il est ainsi possible de remplacer des
données par d’autres données ayant encore du sens après déchiffrement. Pour éviter cela on va
recourir au chaînage de DES, c’est à dire que pour chaque bloc de 64 bits, avant de faire le
chiff
rement, on va faire un OU Exclusif du bloc en cours avec le bloc chiffré précédemment.
Le premier bloc n’ayant pas de bloc précédent, il subira un OU Exclusif avec un vecteur
d’initialisation (VI).


Décodeur 3 vers 8

Encodeur 8 vers 3

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

6
/
36















Ainsi, un même code ou une même suite de bit, ne sera pas codé de la même façon
selon son emplacement dans le texte clair.


Il est possible de casser le chiffrement DES, mais cela est très long et très fastidieux.
Pour y remédier, il est possible de dou
bler le chiffrement, voire de le tripler. On ne connaît
actuellement pas de méthode pour casser un triple DES.



Comment casser une clé

?


L’analyse dite du "texte chiffré connu", le casseur ne connaît que le texte chiffré et
doit en déduire la clé direc
tement. L’analyse du "texte en clair connu", le casseur connaît le
texte en clair et le texte chiffré et doit en déduire la clé. L’analyse du "texte en clair choisi" est
ce qu’il y a de plus simple

: le casseur connaît non seulement le texte en clair, le t
exte chiffré,
mais peut également choisir le contenu du texte clair. C’est par exemple le cas lorsqu’il
réussit à faire crypter clandestinement un texte élaboré par ses soins avec le procédé
recherché. Il peut alors écrire le texte de manière à lui facilit
er le plus possible l’analyse de la
clé.

C’est dire la puissance de cet algorithme, car même si le casseur connaît le maximum
d’informations, il ne peut pas en déduire la clé. Le seul moyen qui lui reste pour trouver la clé
est de chercher toutes les comb
inaisons. Sans compter sur une grande chance, tester toutes les
combinaisons de clé DES à 168 bits n’aboutit pas au résultat durant un temps inférieur à
quelques millénaires …


Il existe de nombreux autres algorithmes de clés secrètes, mais en expliquer l
eur
fonctionnement serait bien fastidieux. Notre propos étant d’expliquer les principes et non pas
le détail des algorithmes, nous ne citerons que les noms des autres algorithmes à clés secrètes
les plus connus pour leur sûreté. Nous ne citerons donc que B
LOWFISH
, S
CHNEIR
, et
IDEA(International Data Encrypting Algorithm).



La difficulté de la clé secrète est de la transmettre de telle sorte qu’elle ne puisse être
interceptée. Il faut pour cela trouver un moyen de transmission plus sécurisé que le réseau.
C’est ce qu’on appelle dans le jargon de la communication transmettre sur un canal sécurisé
(Secure Chanel). Il est par exemple préférable de transmettre la clé lors d’une rencontre en la
donnant par oral. Mais à l’époque du tout informatique ou chacun dés
ire depuis chez lui avoir
C
0
VI
VI
VI

M
0
VI
VI
VI

VI

E

E

E

E

M
3
VI
VI
VI

M
2
VI
VI
VI

M
1
VI
VI
VI

C
1
VI
VI
VI

C
2
VI
VI
VI

C
3
VI
VI
VI

= OU Exclusif

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

7
/
36

accès au e
-
commerce de manière sécurisée, il n’est pas possible de transmettre à tous les
utilisateurs les clés secrètes.

Le gros danger inhérent à la clé secrète est qu’elle est secrète. En effet quiconque
s’accaparant la clé, p
ourra à loisirs traduire les messages interceptés en langage intelligible, il
pourra également les modifier, les répéter ou les supprimer selon son intérêt. En effet c’est la
même clé qui permet de chiffrer et de déchiffrer les messages.


I.3 Les algorith
mes à clé publique.


Il existe des méthodes de chiffrement où la clé de chiffrement ne peut pas se déduire
de la clé de déchiffrement. D
IFFIE

et H
ELLMAN

proposèrent en 1976 cet algorithme où, C la
clé de Chiffrement, D la clé de Déchiffrement, et M le Me
ssage doivent respecter les trois
conditions suivantes

:


1.

D (C (M) ) = M

2.

Il est excessivement difficile de déduire D de C et réciproquement

3.

C ne peut être cassé par une attaque de type "texte en clair choisi".


Principe des algorithmes à clé publique

: A
lice souhaite envoyer son numéro de carte
bancaire à sa banque BigBank. Chaque entité possède deux clés, une clé publique et une clé
privée. La clé publique est diffusée à tous les interlocuteurs avec lesquels chacun désire
dialoguer en toute confidentiali
té.


Système d’Alice






Système de BigBank
























Pour communiquer avec
confidentialité
, l’expéditeur du message Chiffre avec la clé
C qui est la clé publique du destinataire. Le destinataire étant le seul à posséd
er sa propre clé
Internet

Clé pub
lique
de BigBank

Clé privée

de BigBank

Clé privée
d’Alice

C泩⁰畢汩煵攠
摥⁃潰ç楮

C泩⁰畢汩煵攠
摥⁂i杂a湫

C泩⁰l楶

摥⁂i杂a湫

C泩⁰畢汩煵攠
摥⁃汩e湴

C泩⁰畢汩煵攠
d’Alice

Ca牴ê⁢ 湣a楲i

Ca牴ê⁢ 湣a楲i

摳㕱d㙫㑣ua㝭

C泩⁰l楶
d’Alice

C泩⁰畢汩煵攠
d’Alice

C潤ç⁢潮

C潤ç⁢潮

摳㕱d㙫㑣ua㝭

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

8
/
36

privée, il est le seul à pouvoir Déchiffrer avec sa Clé D. Ceci permet de respecter la première
des conditions libellées ci
-
dessus D (C (M) ) = M.

L’intégrité

des données est rendue possible par redondance dans le message crypté.
Ainsi, u
ne modification du message par un intrus sera perceptible, car la donnée transmise
sera altérée et n’aura plus de sens.

L’authentification

relève du même principe que la confidentialité. Ce point va être
éclairci à travers l’explication de l’algorithme RS
A.



I.4 L’algorithme RSA



L’algorithme RSA

tire son nom des initiales de ses inventeurs R
IVEST

S
HAMIR

et
A
DELMAN
. Il a été créé en 1979 pour le MIT. Cet algorithme est fondé sur la théorie des
nombres. Les étapes de l’algorithme sont les suivantes

:

1.

Ch
oisir deux nombres premiers, p et q, chacun plus grands que 10
100


2.

Calculer n= p.q et z = (p
-
1).(q
-
1)

3.

Choisir un nombre d premier avec z

4.

Chercher e tel que e.d = 1 (mod z)


Pour chiffrer un message M, on calcule C

=

M
e

(mod

n). Pour déchiffrer C, on calcul
e
M

=

Cd

(mod

n). On peut démontrer que pour tout message M dans l’intervalle [0,

n[, les
deux fonctions de chiffrement et de déchiffrement sont bien l’inverse l’une de l’autre. Pour
effectuer le chiffrement, il faut connaître e et n. La clé publique de ce
t algorithme est donc le
couple (e,

n)et la clé secrète, le couple (d,

n).

La sécurité de cet algorithme réside dans le fait qu’il est assez facile de factoriser des
nombres premiers, même grands. En revanche, il est très difficile de décomposer de très
g
rands nombres en facteurs premiers. Les mathématiciens n’ayant toujours pas trouvé de
méthode pour résoudre ce problème, la décomposition d’un nombre de deux cent chiffres
nécessite quatre milliards d’années de calcul sur ordinateur.

En réalité RSA est u
n algorithme légèrement trop lent pour qu’on puisse
raisonnablement l’utiliser pour chiffrer de grandes quantités de données. Dans la pratique,
cependant, la plupart des systèmes de cryptographie qui utilisent RSA le font juste pour
distribuer des clés de
session utilisées notamment avec DES.



L’authentification avec RSA

:


RSA est un algorithme à clé publique, donc il obéit à la loi

: D (C (M) ) = M. RSA
offre en plus la particularité suivante

: C (D (M) ) = M, ce qui permet
l’authentification
.

Quelque
s explications

: en temps normal, pour communiquer, l’expéditeur chiffre le
message à émettre avec la clé publique du destinataire puis lui envoie le message. Pour
l’authentification, c’est le contraire

: moi, l’expéditeur envoie un message crypté à l’aide

de
ma clé privée. Ce dernier pourra s’assurer que c’est bien moi qui le lui ai envoyé. En effet, ma
clé privée est la seule qui puisse créer un cryptogramme déchiffrable par ma clé publique

!
(ceci est faisable avec RSA car C (D (M) ) = M = D (C (M) ) ).


RSA est, avec DES, le deuxième pilier de l’échange de données sécurisé. RSA est
devenu publique depuis septembre 2001. De nombreux produits et protocoles très répandus y
font appel, par exemple S
-
HTTP et SSL. Ces sujets seront abordés plus loin.

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

9
/
36


Authen
tification avec Kerberos

:


Kerberos est un protocole d’authentification que beaucoup de systèmes réels utilisent.
C’est pourquoi nous allons développer en quelques lignes les principes directeurs.

Kerberos fait appel à trois serveurs

:

-

SA, le serveur d’
authentification qui vérifient l’identité des utilisateurs qui se
connectent

-

ST, le serveur de tickets, "preuve d’identité"

-

B, le serveur distant avec lequel le client A veut dialoguer

Ce protocole est intéressant puisqu’il permet à n’importe quel utilisat
eur de se
connecter depuis n’importe quel poste de travail. L’utilisateur envoie son login au SA en texte
clair. Il lui revient une clé de session et un ticket. Il réemet le ticket auprès du serveur de
ticket. Le ST prend le ticket et lui renvoie une clé d
e session qui permettra le dialogue avec B.
Puis l’utilisateur A entre enfin en rapport avec B.



I.5 Authenticité et tiers de confiance


L’authenticité de nombreux documents légaux est liée à la présence de signatures
manuscrites. Quel en est l’équivalent

pour le format numérique

?


Prenons l’exemple d’un client qui souhaite passer commande de 10 tonnes d’or auprès
de son courtier. Il existe 2 cas qui peuvent engendrer un litige

:

-

la banque achète les 10 tonnes d’or, et immédiatement après le cours de l’
or
s’effondre. Le client malhonnête pourrait poursuivre sa banque en disant qu’il n’a jamais
demandé l’achat de cet or. Le client annoncerait en justice qu’il n’est pas l’auteur du message.

-

le cours de l’or augmente brusquement. La banque est alors tentée

de
construire un message signé dans lequel le client demande un lingot d’or au lieu d’une tonne.


La solution est de passer par une "Haute Autorité". Cette dernière sera la réponse au
principe de
non
-
répudiation
. Il faut que cette autorité soit un tiers
de confiance. Chaque
utilisateur choisit une clé secrète et la dépose lui
-
même chez ce tiers. Ce tiers sert
d’intermédiaire entre chaque utilisateur. Ainsi, lorsque le Client A veut envoyer un message
M en clair signé à son Banquier B, pour cela, il le cry
pte, et l’envoie au tiers de confiance
(TC). TC le déchiffre, puis réexpédie au destinataire B un message qui contient le message de
A.









t est une horodate permettant de déjouer des attaques de type rejeu.


Ainsi, si A dénie son envoi, au t
ribunal, B apporte le document contenant
K
B
(A,t,M,K
TC
(A,t,M)). Il apporte notamment le morceau de message K
TC
(A,t,M). Le tiers de

A


TC


B

A, K
A
(B,t,M)

K
B
(A,t,M,K
TC
(A,t,M))

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

10
/
36

confiance étant le seul à avoir pu écrire ce message, il décrypte ce cryptogramme qui prouve
que A a bel et bien envoyé le me
ssage M à la date t. De même si B a modifié un message
provenant du client A, il ne pourra s’en servir de preuve auprès du tribunal, car le tiers de
confiance ne pourra avoir envoyé le message, vu que B n’aura pu utiliser la clé privée de TC.



II Juridic
tion


Mais qu’est
-
ce qu’un tiers de confiance. En France, le SCSSI (Service Central de la
Sécurité des Systèmes d’Information) service français qui dépend du Premier ministre, est
l’organisme chargé de recueillir les demandes d’autorisation et les déclarat
ions d’utilisation
ou de commercialisation de logiciel de cryptage utilisant une clé supérieure à 40 bits. Un tiers
de confiance doit donc être référencé auprès du SCSSI.


Il existe des lois auxquels tout utilisateur informatique doit se soumettre.


Ces l
ois sont les suivantes.

:

-

loi n° 90
-
1170 du 29.12.1990 article 28 (JO 30.12.1990)

-

modifié par la loi n° 96
-
656 du 26.07.1996 article 17 (JO 27.07.1996)

-

décret n°98
-
101 du 24.02.1998 (JO du 25.02.1998)

-

3 arrêtés du 13.03.1998 (JO 15.03.1998)

-

décrets n°98
-
2
06 et n°98
-
207 du 23.03.1998 (JO 25.03.1998)


Pour plus de renseignement, le site du gouvernement français
http://www.ssi.gouv.fr/fr/reglementation/index.html




Opérations

Applicati
ons

Authentification

Signature

Intégrité

Confidentialité

Longueur de clé

< ou = 40 bits

< ou = 128 bits

>128 bits

Fourniture

Soumise à
déclaration
simplifiée

Soumise à
déclaration

Soumise à
déclaration

Soumise à
autorisation

Importation

LIBRE

LIBRE

LIBRE

Soumise à
autorisation

Utilisation

LIBRE

LIBRE

LIBRE

AUTORISEE






En résumé
, fournir ou importer des clés de longueur supérieures à 40 bits doivent être
simplement déclarées auprès du SCSSI. Fournir ou importer de clés supérieures à 128 bits
sont

soumis à autorisation du SCSSI. Donc pour faire des échanges de données sécurisées, on
utilise le chiffrement triple
-
DES (clés symétriques de 64 à 168 bits). Pour s’échanger ces clés,
Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

11
/
36

il faut utiliser l’algorithme RSA qui nécessite des clés privées de 128

bits et des clés
publiques de 1024 ou 2048 bits.




III Les transactions sécurisées


La sécurisation des transactions sur Internet peut se faire par différents moyens
utilisant les techniques décrites ci
-
dessus (authentification, chiffrement …), ces moye
ns
pouvant être utilisés conjointement. Nous allons présenter les principales solutions
implémentées et utilisées dans le monde du commerce électronique (SSL, SET, et autres plus
anecdotiques)


III.1 Le protocole SSL (Secure Sockets Layer)


III.1.1 Histori
que


Développé par Netscape (1994), SSL est un protocole qui permet d’établir une
communication «

sécurisée

» entre un client (le navigateur) et un serveur (site Internet). Le
brevet a été racheté par l’IETF et rebaptisé TLS (Transport Layer Security)

SSL

a deux fonctions essentielles

:

o

authentifier le serveur auquel l’utilisateur est connecté

o

assurer la confidentialité des informations transmises par son intermédiaire au
moyen d’algorithme de chiffrement.



III.1.2 Fonctionnement


Le protocole SSL fonctio
nne entre les protocoles TCP/IP et les protocoles de plus haut
niveau http, ftp… comme le montre la figure suivante. Il permet au serveur de s’identifier lui
-
même auprès du client, réciproquement le client auprès du serveur, et aux deux d’établir une
conne
xion cryptée.


Une session SSL commence lorsqu’une URL spéciale commençant par https est
demandée, le client se connecte alors sur le port 443.





source : Netscape Communication Corporation


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

12
/
36

Dans le détail, ces opérations s’e
ffectuent de la façon suivante

:


L’authentification du serveur SSL

permet au client de confirmer l’identité du
serveur

: le logiciel côté client utilise les techniques standard de cryptographie à clé publique
pour vérifier que le certificat du serveur et
son identifiant public, ont été produits par un
organisme certificateur agréé par le client.

Cette confirmation est importante pour le client si par exemple, s’il envoie son N° de
carte bancaire à travers le réseau et veut s’assurer de l’identité du serve
ur récepteur.


L’authentification du client SSL

permet au serveur de confirmer l’identité du client

:
c’est le même procédé que celui utilisé pour l’authentification du serveur.

Cela peut être important dans le cas où le serveur est une banque, qui veut t
ransmettre
une information financière à son client et donc vérifier l’identité du destinataire.


Une
connexion cryptée SSL

implique que toutes les données échangées entre un
client et un serveur soient cryptées par le logiciel expéditeur et décryptées par
le logiciel
destinataire, ce qui introduit un degré élevé de sécurité. Toutes les données envoyées au
moyen d’une connexion cryptée SSL sont protégées par un mécanisme contre les
manipulations, qui garantit que les données n’ont pas été modifiées dans leur

transit.

Le protocole SSL inclut deux sous protocoles

:

-

Le protocole SSL handshake.

-

Le protocole SSL record.

Le protocole SSL record définit le format utilisé pour transmettre les données.

Le protocole SSL handshake implique l’utilisation du protocole SSL

record pour échanger
une série de messages entre le serveur et le client lorsqu’ils établissent leur première
connexion.

Cet échange de message sert à mettre en place les actions suivantes :

-

Authentification du serveur par le client

-

Permettre au client et

au serveur de choisir les algorithmes de
chiffrements qu’ils supportent conjointement

-

Authentification du client par le serveur (optionnel)

-

Utiliser les techniques de cryptage à clef publiques pour générer

des
secrets partagés

-

Etablir une connexion SSL cr
yptée


III.1.3 Le chiffrement utilisé avec SSL

Le protocole SSL supporte l’utilisation d’un grand nombre d’algorithmes de cryptage
différents, notamment pour les opérations d’authentification, de transmission de certificats et
d’établissement de clés de s
ession.

Le client et le serveur peuvent supporter différents niveaux de chiffrements qui dépendent de
la version SSL, des polices d’assurance qui imposent un niveau de cryptage acceptable et des
dispositions législatives de chaque pays concernant l’exporta
tion.

En tenant compte de ces informations, le protocole SSL détermine comment le serveur et le
client vont négocier l’algorithme de chiffrement qu’ils vont utiliser pour s’authentifier
mutuellement, transmettre les certificats et établir leur clé de sessi
on.


Les chiffrements qui suivent font référence aux algorithmes suivants :



DES

: Data Encryption Standard,



DSA

: Digital Signature Algorithm, algorithme utilise pour la signature numérique.

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

13
/
36



KEA

: Key Exchange Algorithme, pour échange de clés.



MD5
: Me
ssage Digest algorithm developed by Rivest.



RC2 and RC4
: Algorithmes de chiffrement.



RSA

: Algorithme de clés publiques pour cryptage et authentification.



RSA Key Exchange
:

Algorithme d’échange de clés pour SSL basé sur RSA.



SHA
-
1

: Secure Hash Algor
ithm, fonction de hachage.



SKIPJACK

: Algorithme classifié de clés symétriques



Triple
-
DES

:DES appliqué trois fois.


Les algorithmes d’échange de clés tels que KEA ou RSA Key Exchange régissent la façon
dont le serveur et le client vont déterminer les c
lés symétriques qu’ils vont utiliser durant la
session SSL.

Lors de l’échange d’information pendant le protocole SSL handshake, le client et le serveur
identifient le niveau de chiffrement le plus élevé commun, c’est celui qu’ils utiliseront pour la
sessio
n SSL.

Le niveau de chiffrement qu’une société met en œuvre dépend de plusieurs facteurs

:

-

la sensibilité des donnés impliquées

-

le rapidité du chiffrement

-

l’application des lois à l’exportation.



Chiffrements supporté par le protocole SSL, en utilisant l
’algorithme RSA Key Exchange

:

-

chiffrement le plus faible

: s’il n’y a pas besoin de cryptage des données, mais
uniquement besoin de l’authentification la plus basique, il sera possible d’utiliser MD5. MD5
repère les altérations des données lors de l’aut
hentification

-

pour crypter des données confidentielles

: RC2
-
40, et RC4
-
40 permettent tous deux de
crypter des données à l’aide d’une clé de 40 bits. Les deux sont associés à l’authentification
MD5. RC2 et RC4 permettent plus de 10
12

clés, mais RC4 est un
algorithme plus rapide.

-

pour crypter des données de haute confidentialité, les cryptages suivants sont
suffisamment forts pour la plupart des transactions et données gouvernementales

: le DES
-
56
utilise des clés de 56 bits soit plus de 10
16

clés possibles
, le RC2
-
128 et RC4
-
128 utilisent des
clés de 128 bits soit plus de 10
38

clés possibles.

-

chiffrement le plus fort, qui convient aux données de très haute confidentialité utilisées
par les banques

: le triple DES
-
168, avec l’authentification SHA
-
1. Le tr
iple DES utilise des
clés trois fois plus longue que le DES
-
56 standard. Avec des clés de 168 bits, il existe plus de
10
50

clés possibles. On ne connaît toujours pas de méthode pour casser un triple DES dans des
délais humains (quelques millénaires).



III
.1.4 Le protocole handshake


Le protocole SSL utilise une combinaison de clés publiques et de clés symétriques. Une
session SSL commence toujours par un échange de message appelé SSL hanshake. Il permet
au serveur de s’identifier lui
-
même auprès du client

en utilisant une technique de clé publique
et permet alors au client et au serveur de coopérer dans la création de clés symétriques
utilisées pour le cryptage, le décryptage et la détection de bidouillage durant la session qui
suit.


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

14
/
36

Optionnellement, le h
andshake protocole permet aussi au client de s’authentifier auprès du
serveur.

Voici le résumé des différentes étapes

; un schéma les synthétise sur la page suivante.

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

15
/
36




1
-
Version SSL

-

chiffrement
disponible

-

donnée aléatoire

2
-
Version SSL

-

chiffrement
disponi
ble

-

donnée aléatoire

-

certificat

-

----------------------

-

demande de
certificat

4
-

Premaster Secret

-------------------------

5
-

Certificat client

-

donnée commune
signée

8
-

Message

:

«


les
messages vont être
cryptées avec


la clé de
session»

-
Message crypté

:

«

fin
du protocole
handshake

»


9
-

Message

:

«


les
messages vont être
cryptées avec


la clé de
session»

-
Message crypté

:

«

fin
du protocole
handshake

»


3


䅵瑨A湴n晩fa瑩潮ç


摵⁳d牶ê畲



䕬b扯牡瑩潮⁤甠
浡獴m爠獥c牥t


T
-
䕬b扯牡瑩潮⁤ç猠c泩猠
摥⁳ 獳s潮ç

潵ç

湯n

䕃䡅b




䕬b扯牡瑩潮ç 摵d
浡獴
e爠獥c牥t


T
-
䕬b扯牡瑩潮ç 摥猠 c泩l
摥⁳ 獳s潮ç

䅵瑨A湴n晩fa瑩潮ç
C汩e湴


湯n

潵ç

䕃䡅b

㄰N

䓩扵琠摥b⁳ 獳s潮çppi

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

16
/
36


1
-

le client envoie au serveur sa version SSL, le

chiffrement disponible, une donnée générée
aléatoirement, plus diverses informations dont le serveur a besoin pour communiquer avec le
client SSL.


2
-

le serveur envoie au serveur sa version SSL, le chiffrement disponible, une donnée générée
aléatoiremen
t, plus diverses informations dont le client a besoin pour communiquer avec le
serveur au moyen de SSL. Le serveur envoie aussi son propre certificat et si le client a besoin
d’accéder à une ressource serveur qui demande une authentification, il demande un

certificat
au client.


3
-

le client utilise une partie des informations envoyées par le serveur pour authentifier le
serveur (voir § authentification serveur).Si le serveur ne peut pas être identifié, alors
l’utilisateur est averti que la communication n
’a pu être établie.


4
-

Utilisant toutes les données générées par le handshake ci
-
dessus, le client (en collaboration
avec le serveur et en fonction du chiffrement utilisé) crée le premaster secret propre à la
session, le crypte avec la clé publique du s
erveur (obtenue à l’étape 2, dans le certificat) et
l’envoie au serveur.


5
-

Si le serveur a demandé un certificat d’authentification alors, le client signe aussi une
partie des données qui est propre à ce handshake et connue par les 2 parties. Dans ce ca
s, le
client envoie la donnée signée et le certificat en même temps que le premaster secret au
serveur.


6
-

Si le serveur a requis une authentification alors il attend pour authentifier le client. Si le
client n’est pas identifié alors la session est term
inée. Si l’opération est positive, le serveur
utilise sa clé privée pour décrypter le premaster secret. Le serveur et le client démarrent alors
un processus pour générer le master secret à partir du même premaster secret.


7
-

Ensemble, le client et le ser
veur utilisent le master secret pour générer des clés de session
qui sont des clés symétriques pour crypter et décrypter les infos échangées durant la session
SSL et vérifier leur intégrité (en fait, détecter toute modification entre le moment où elles so
nt
envoyées et le moment où elles sont reçues).


8
-

Le client envoie un message au serveur pour l’informer que tous les futurs messages seront
cryptées avec la clé de session. Il envoie aussi un message séparé (crypté) pour dire que la
partie handshake es
t terminée.


9
-

Le serveur envoie un message au client pour l’informer que tous les futurs messages seront
cryptées avec la clé de session. Il envoie aussi un message séparé (crypté) pour dire que la
partie hanshake est terminée.


10
-

le protocole handsh
ake est alors terminé et la session SSL commence.







Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

17
/
36

III.1.5 L’authentification du serveur (par le client)


Le logiciel client SSL a toujours besoin de l’authentification du serveur ou d’une validation
cryptée par le client. Comme expliqué à l’étape 2 d
u protocole SSL handshake, le serveur
envoie au client un certificat pour s’authentifier lui
-
même. Le client utilise le certificat à
l’étape 3 pour authentifier l’identité que le certificat prétend représenter.

Pour authentifier le lien entre la clé publiq
ue et le serveur identifiée par le certificat (qui
contient la clé publique), le client doit répondre par "oui" aux quatre questions suivantes.
Bien que la quatrième question ne fasse pas partie intégrante du protocole SSL, c’est de la
responsabilité du c
lient de supporter ce besoin qui apporte une assurance supplémentaire sur
l’identité du serveur et qui prévient d’une attaque appelée «

l’homme du milieu

»





source : Netscape Communication Corporation


1. Est
-
ce que la date
d’aujourd’hui appartient à la période de validité

?

Le client vérifie la période de validité du certificat du serveur. Si la date et l’heure courant
n’appartiennent pas à cet intervalle de temps, alors le processus d’authentification s’arrête

;
dans le cas

contraire le client continue à l’étape 2.



2. Est
-
ce que l’autorité de certification émettrice est une autorité de confiance

?

Chaque client SSL maintient une liste d’autorités de confiance. Cette liste détermine quels
certificats de serveur le client a
ccepte. Si le nom de l’autorité de certification correspond avec
un de la liste du client alors la réponse est "oui" et le client continue à l’étape 3.


3. Est
-
ce que la clé publique de l’autorité de certification correspond à la signature numérique
de l’
autorité de certification ?

Le client utilise la clé publique du certificat de l’autorité de certification pour valider la
signature numérique de l’autorité de certification présentée sur le certificat du client. Si
Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

18
/
36

l’information contenu dans le certificat

du serveur à changer depuis la signature par l’autorité
de certification ou si la clé publique du certificat de l’autorité ne correspond pas à la clé privée
utilisée par l’autorité pour signer le certificat du serveur, l’authentification a alors échoué.

Sinon le client considère que le certificat du serveur est valide.


4. Est
-
ce que le nom de domaine inclus dans le certificat correspond au nom du serveur

?

Cette étape confirme que le serveur est actuellement localisé à la même adresse réseau
spécifié par

le nom de domaine du certificat. Cette étape ne fait pas partie intégrante du
protocole SSL mais elle permet de se protéger d’une attaque connue sous le nom «

homme du
milieu

». Le client doit valider cette étape et doit refuser d’établir la connexion si
le nom de
domaine actuel ne correspond à celui du certificat.

Si la comparaison est positive alors on passe à l étape 5.


5. le serveur est authentifié.


Si le client n’atteint pas l’étape 5 pour quelque raison que ce soit, la connexion SSL ne peut
être ét
ablie et l’utilisateur en est averti.



III.1.6 L’authentification du client (par le serveur)


Les serveurs SSL peuvent être configurés pour demander une authentification client ou une
validation cryptée de l’identité du client. Quand le serveur est config
uré ce cette façon, (étape
6 du protocole handshake), le client envoie au serveur un certificat et une partie des données
signées numériquement pour s’authentifier lui
-
même. Le serveur utilise les données signées
numériquement pour valider la clé publique
contenu dans le certificat et authentifier l’identité
que prétend représenter la certificat.

Le protocole SSL demande au client de créer une signature numérique générée en hachant
une partie des données aléatoires du protocole handshake, connues uniquemen
t du serveur et
du client. La donnée hachée est alors cryptée avec la clé privée qui correspond à la clé
publique contenue dans le certificat présenté, au serveur.

Pour authentifier le lien entre la clé publique et la personne ou l’entité identifiée par le

certificat qui contient la clé publique, le serveur SSL doit recevoir une réponse positive aux
cinq premières questions qui suivent.

Bien que la cinquième question ne fasse pas partie du protocole SSL, le serveur SSL peut être
configuré pour supporter ce
tte demande pour que l’entrée de l’utilisateur dans un annuaire
LDAP soit utilisée dans le processus d’authentification.


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

19
/
36



source : Netscape Communication Corporation



Le serveur va suivre les étapes suivantes pour authentifi
er l’identité du client

:


1
-

Est
-
ce que la signature numérique de l’utilisateur est validée par la clé publique de
l’utilisateur?

Le serveur vérifie que la signature numérique du client peut être validée avec la clé publique
du certificat. Si oui, le ser
veur a alors établi que la clé publique qui appartient à John Doe
correspond à la clé privée utilisée pur créer la signature et que les données n’ont pas été
"bidouillées". Cependant à cette étape, le lien entre la clé publique et le nom de domaine
indiqué

dans le certificat n’a pu être établi. Le certificat peut avoir été crée par quelqu’un qui
essaie d’usurper l’identité de l’utilisateur. Pour valider le lien entre la clé publique et le nom
de domaine, le serveur doit aussi réaliser les étapes 3 et 4.


2
-

Est
-

ce que la date courante appartient à la période de validité du certificat

?

Le serveur vérifie la période de validité du certificat. Si l’heure et la date ne font pas partie de
cet intervalle, alors le processus d’authentification se termine par un

échec.


3
-

Est
-
ce que l’autorité de certification émettrice est une autorité de certification de
confiance

?

Le serveur SSL maintient à jour une liste de certificats (provenant d’autorité (de certification)
de confiance). Cette liste détermine quels cert
ificats le serveur va accepter. Si le nom de
domaine de l’autorité de certification correspond à un nom de domaine des autorités de
certification autorisées, alors la réponse est positive.

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

20
/
36

C’est le rôle des administrateurs de vérifier si les certificats d
es autorités de certifications
sont valides ou non en contrôlant la liste des certificats du serveur et du client.


4
-

Est
-
ce que la clé publique de l’autorité de certification valide la signature numérique de
l’émetteur

?

Le serveur utilise la clé publi
que du certificat (fournie par la liste des autorités de
certifications) pour valider la signature numérique de l’autorité de certification du certificat
présenté. Si l’information du certificat a changé depuis qu

’il a été signé par l’autorité de
certific
ation ou si la clé publique du certificat ne correspond pas à la clé privée utilisée par
l’autorité de certification pour signer le certificat alors le serveur ne peut authentifier l’identité
de l’utilisateur. Si la signature numérique est validée, alors l
e serveur traite le certificat de
l’utilisateur comme une "lettre d’introduction" valide de la part de l’autorité de certification.
De ce point de vue, le protocole SSL considère que le client est authentifié et la connexion se
poursuit comme décrit à l’ét
ape 6. Le serveur peut être configuré de façon à ce que l’étape 6
se déroule avant l’étape 5.


5
-

Est
-
ce que le certificat du client est listé dans l'entrée LDAP du client

?

Cette étape optionnelle est une possibilité pour l’administrateur de révoquer un
certificat
d’utilisateur même s’il a passé tous les tests précédents. Pour les serveurs configurés de cette
manière, ils peuvent refuser de valider un certificat ou d’établir la connexion. Si le certificat
du client du répertoire LDAP est identique à celui

présenté dans le handshake protocole, le
serveur passe alors à l’étape suivante.


6
-

Le client identifié est
-
il autorisé à accéder à la ressource demandée?

Le serveur vérifie que les ressources auquel le client est autorisé à accéder, correspondent à sa

liste de contrôles d’accès, et établit alors l’accès approprié.

Si l’étape 6 n’est pas atteinte, l’utilisateur identifié par le certificat ne peut être authentifié et
dans ce cas, il ne peut accéder à aucune ressource du client qui demande une authentific
ation.



III.1.7 Faiblesses


Si le protocole SSL peut paraître infaillible, il n’en est rien

:

Ses éventuelles faiblesses proviennent de la façon dont on l’implémente

:


-

1
-

l’attaque de l’homme du milieu (cas où l’authentification du client n’est pas
util
isée).

Un tiers s’intercale dans la communication entre le client et le serveur, profitant de
l’absence d’authentification du client en générant les paires de clés appropriées.


-

2
-

une faiblesse de SSL (article du LASEC de L’EPFL)

Cette faiblesse réside s
ur le Birthday Paradox, c’est à dire que quand 23 personnes sont
enfermées dans une même pièce, il y a plus de 50% de chance que deux personnes aient la
même date de naissance. Le raisonnement est identique pour le nombre de clés.

Pour plus de précisions,
vous pouvez consulter les liens suivants

:

http://lasecwww.epfl.ch/query.msql?ref=Vau01

http://sic.epfl.
ch/SA/publications/FI00/fi
-
sp
-
00/sp
-
00
-
page6.html


-

3
-

la longueur de clé (utilisée pour le chiffrement)

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

21
/
36

Les algorithmes utilisant des clés de 40 bits sont «

crackables

». Des étudiants américains
en 1997, l’ont réussi en un peu plus de 3 h à partir d’un
simple PC, la barrière à
«

craquer

» actuellement est de 64 bits.


80% des transactions du e
-
commerce sont sécurisées au moyen de SSL , preuve de sa fiabilité.
Il existe cependant d’autres solutions, principalement le protocole SET et son dérivé C
-
SET.



I
II.2 Le protocole SET


III.2.1 Historique

:

SET (Secure Electronic Transaction) est un protocole de sécurisation des transactions
électroniques mis au point par Visa et MasterCard, et s'appuyant sur la méthode SSL.

SETCo est l’organisation créée Visa et Ma
sterCard, pour accélérer l'adoption du module de
paiement sécurisé SET


II.2.2 Scénario

SET est basé sur l'utilisation d'une signature électronique au niveau de l'acheteur et une
transaction mettant en jeu non seulement l'acheteur et le vendeur, mais auss
i leur banque
respective.

Lors d'une transaction sécurisée avec SET, les données sont envoyées par le client au serveur
de l'acheteur, mais ce dernier ne récupère que la commande. En effet, le numéro de carte
bleue est envoyée directement à la banque du c
ommerçant, qui va être en mesure de lire les
coordonnées bancaires de l'acheteur, et donc de contacter sa banque afin de les vérifier en
temps réel.(voir figure qui suit)

Le numéro de carte ne peut plus être stocké sur le serveur du site marchand par mégar
de ou
pour faciliter de futurs achats, donc il est moins vulnérable.

Un degré supplémentaire de confidentialité est apporté car le commerçant n’a pas
connaissance du numéro de carte et la banque n’a pas connaissance de la nature des achats du
client.

Sché
ma d’une transaction SET


















C
ommerçant


Client



Banque


Commande

N°carte
bancaire

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

22
/
36

Ce type de méthode nécessite une signature électronique au niveau de l'utilisateur de la carte
afin de certifier qu'il s'agit bien du possesseur de cette carte.


En
résumé
,




SSL est un protocole de paiement permett
ant d'effectuer de manière sécurisée des
transactions par carte bancaire sur réseaux ouverts.



SSL est plus sûr que SSL, l’amélioration réside dans le fait que le n°carte bancaire
ne transite plus par le site marchand



SSL permet l’authentification du clien
t et du commerçant



Il nécessite un logiciel spécifique sur le PC du client (le "Wallet")



Il utilise deux paires de clés publique / privée par entité

:

o

Une paire pour signer

o

Une paire pour échanger des clés symétriques



Il fait intervenir 3 types d'acte
urs :

o

le fournisseur (commerçant)

o

l'utilisateur (client)

o

le serveur de paiement (géré par la banque du fournisseur)



Bilan SET

:

Avantages

: sécurité, transactions proches de celles du "monde conventionnel"

Inconvénients

: complexité (3 intervenants),

coût élevé, faible pourcentage de clients
équipés.


Le logo d’un site sécurisé par SET

:



Support d’informations

:

http://www.commentcamarche.net/crypto/set.htm

http://www.hitech
-
azur.asso.fr/old/fudip/livret6/slide7
-
0.html


Le protocole C
-
SET qui met en œuvre le protocole SET, utilise un lecteur de carte bancaire
sécurisé (branché sur le PC du client). Le

fait de taper le code bancaire (donc de le connaître)
apporte une assurance supplémentaire sur l’identité du client.

La mise en œuvre d’une solution C
-
SET paraît difficilement applicable pour une société
(comment définir l’attribution du lecteur et de la
carte

?).

Les principaux freins sont le prix du lecteur, la mise en œuvre du protocole SET et le nombre
de sites agrées SetCO.


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

23
/
36


III.3 Odysséo


La grande peur de l’utilisateur est le fait que le n° carte bancaire circule sur le réseau

; une
solution possi
ble est un portefeuille virtuel que vous avez préalablement approvisionné
(virement, prélèvement) et à ce moment
-
là, vous n’avez plus besoin de faire circuler le n° de
carte bancaire sur le réseau. Vos coordonnées bancaires auront été utilisées une seule f
ois, à la
création de votre portefeuille. C’est l’organisme tiers qui détient votre portefeuille qui recevra
une demande paiement du site marchand et qui vous demandera de la valider par une
signature numérique.

Le montant du portefeuille est limité

; au
-
d
elà de ce montant, il faut utiliser sa carte bancaire
de manière conventionnelle.

Pour plus de détails

:

http://www.vnunet.fr/actu/article.htm?numero=7150

http://www.odysseo.com/



Conclusion

:


Le protocole SSL présente des faiblesses certes, mais elles ne peuvent pas être
exploitables par n’importe qui. On peut s’en prémunir en soignant son implémentation (clé de
chiffrement 128bits, authe
ntification...). Sa facilité de mise en œuvre laisse à penser que SSL
va continuer à jouer un rôle majeur dans la sécurisation des transactions.

Les solutions implémentant le protocole SET, ont l’avantage de présenter une sécurité
accrue ; elles sont encou
ragées par les banques qui sont fortement impliquées. On ne dispose
pas à ce à ce jour, d’un recul suffisant pour juger la solution du portefeuille virtuel (type
Odysséo).

Au vu des protocoles étudiés, on peut penser que les données confidentielles ne sont

pas forcément le plus en danger pendant leur transit sur le réseau mais lors de leur stockage
sur le site client ou le serveur marchand.



IV Solutions et architectures commerciales


Nous allons vous donner quelques pistes pour répondre aux questions conc
rètes auxquelles
vous pouvez être confrontés

:

-

choix d’une infrastructure

-

choix d’un logiciel

-

choix ou renouvellement d’un certificat



IV.1Les offres complètes


Cas ou vous devez implanter un projet e
-
commerce pour une société. Celle
-
ci commerce de
manièr
e traditionnelle et ne possède aucune infrastructure dédiée. La plus simple des solutions
est de consulter les constructeurs qui peuvent vous fournir une gamme de serveurs et des
solutions logicielles complètes

:

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

24
/
36



-

les constructeurs informatiques IBM, HP


-

La société IBM propose la suite logicielle

IBM WebSphere Commerce Suite
et les serveurs de la gamme Netfinity.

http://www
-
5.ibm.com/e
-
business/fr/components/e
-
commerce/solutions/
-

e
-
commerce%20et%20business%20Consulting

Vous trouverez à l’adresse suivante un petit guide en ligne qui vous permet de
cibler vos besoins.

http://www
-
5.ibm.com/e
-
business/fr/components/e
-
commerce/solutions/


-

La société HP fournit une l’infrastructure(serveurs HP) et a développé des
partenariats avec des éditeurs spécialisés tels que BroadVision, Intershop.


http://www.France.hp.com
/solutions
-
entreprise/e_commerce.php3



IV.2 Les solutions logicielles


Vous disposez déjà de matériel informatique, un ou plusieurs serveurs dédiés et vous devez
mettre en ligne une so
lution pour vendre des produits ou offrir des services

: il faut alors
déterminer qui seront les clients, des entreprises ou des particuliers

?

Dans le premier cas, c’est ce qu’on appelle du B2B (Business to Business), dans le deuxième
cas B2C (Business t
o Consumer)

Le B2B ce n’est pas uniquement de la vente en ligne, comme on pourrait le penser en tant que
simple particulier. Le B2B peut être par exemple, des relations clients fournisseurs
(Externalisation d’un service Achats).


-

les offres B2B


Le march
é est dominé par des "petits" éditeurs de logiciels (Commerce One est inconnu du
grand public mais est un des leaders du marchés). Cette situation ne devrait pas durer car le
prix des licences pour les logiciels B2B est élevé et génère un chiffre d’affaire

important pour
les éditeurs. Oracle annonce son arrivée d’ailleurs, sur ce marché et devrait faire une offre
commerciale pour l’année 2002 notamment pour les logiciels de "sourcing" (automatisation
des achats en ligne).


L’offre Commerce One

Site en angla
is avec guide en ligne.

http://www.commerceone.com/



-

les offres B2C


Microsoft dispose d’une gamme complète de solutions B2B et B2C avec son produit
Commerce Server 2000 .

L’offre Microsoft est citée car

ses systèmes d’exploitation dominent le marché des OS mais
l’offre B2C est très importante .

http://www.microsoft.com/commerceserver/

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

25
/
36

http:/
/www.microsoft.com/business/


IV.3 L’offre commerciale C
-
SET


Une solution C
-
SET appliquant SET, est commercialisée par la société Cyber
-
Comm, l’un des
acteurs principaux du marché français. Après installation du lecteur de carte bancaire et du
logiciel,

elle permet aux utilisateurs particuliers d’acheter sur Internet dans un contexte proche
du commerce traditionnel. Cette solution garantit également un paiement aux commerçants.


Cette société est citée car nous montrerons un de ces produits lors de la so
utenance, et leur
site est très clair.

www
.cyber
-
comm.fr


IV.4 Les organismes certificateurs


Votre site de commerce est au point techniquement, votre offre commerciale est au point. Il
faut maintenant que les

clients puissent acheter en toute confiance et d’autre part, que vous
ayez des clients sérieux. C’est le rôle du certificat. De plus, si vous voulez contracter une
assurance contre les actes de malveillance, l’organisme auprès duquel vous souscrivez,
exig
era sûrement un certificat.


Les certificats


Durant les étapes 2 et 5 du protocole handsake, le client et le serveur peuvent échanger des
certificats. Les certificats jouent un rôle essentiel dans le processus d’authentification.

Un certificat doit être
délivré par une autorité de certification et doit contenir :



la clé publique de l'entité à identifier,



le numéro de série du certificat,



la période de validité du certificat,



le nom de domaine de l'entité à identifier,



le nom de domaine de l'autorité d
e certification ayant délivré ce certificat, et



la signature numérique de l'autorité de certification.

En général, la période de validité est d’un an.


Principaux organismes certificateurs

:

Français

:

-

Certplus

www.certplus.com

-

Thawte

www.fr.thawte.com

Anglais

:

-

Verisign

www.verisign.com


Voir jointe en annexe, l’offre Certplus


Comme le conseille Certplus, dans

le cadre d’une activité e
-
commerce, il est recommandé de
choisir l’offre Certificat Serveur Global (chiffrement SSL avec une clé à 128 bits).

Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

26
/
36

Dans le cas d’une application e
-
commerce, les clés publiques sont généralement de 1024 bits
et celles de chiffrem
ent de 128 bits.



IV.5 L’authentification unique


Le principe est d’avoir un seul identifiant pour aller de sites en sites, entre autre pour aller
faire des achats sur différents sites sans avoir à renouveler son identification. L’idée est
intéressante m
ais elle pose plusieurs points d’interrogation

:

-

La confidentialité des données personnelles fournies pour élaborer l’identifiant.

-

L’orientation sur des sites qui sont équipés du logiciel. Ce n’est donc pas un accès
universel.

-

Identifiant qui est très lié

au système d’exploitation puisque à ce jour, seul Microsoft a
une solution opérationnelle.


L’offre Microsoft : Passport dans l’offre .Net intégrée dans Windows XP

;pour plus
d’information consulter le lien suivant

:


http://www.passport.com/Consumer/default.asp?lc=1036




L’offre concurrente

: Liberty Alliance

Liberty Alliance est un regroupement mondial de constructeurs informatiques, d’opérateurs
télécoms et d’autres grandes soci
étés tel que Sun, HP, France Telecom. En 2002, il devrait
proposer un autre système qui soit plus ouvert, entre autre par rapport aux plates
-
formes
logicielles.





Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

27
/
36

V Annexe


Glossaire


1.

Confidentialité

: elle rend compte du fait que seuls les utilisateurs

habilités doivent
pouvoir prendre connaissance de l’information.


2.

Authentification

: est le moyen d’avoir la certitude que l’entité avec laquelle on dialogue
est bien celle que l’on croit.


3.

Non répudiation

: elle concerne les signatures

: comment prouver

qu’un client a bien passé
électroniquement une commande de 10 millions de scoubidous à 89 centimes alors qu’il
prétend que le prix était de 69 centimes.


4.

Contrôle d’intégrité

: est le moyen de s’assurer que le message que l’on reçoit est bien
celui qui a

été envoyé et qu’il n’a donc pas été altéré en cours de route.


5.

Signature

numérique: assure l’authenticité d’un document numérique.


6.

Cryptologie

: études des méthodes de chiffrement (= cryptographie et cryptanalyse)


7.

Cryptogramme

: message créé par un ch
iffrement


8.

Cryptographie

: conception des méthodes de chiffrement


9.

Cryptanalyse

: cassage des méthodes de chiffrement


10.

DES

: Data Encryption Standard


11.

NSA

: National Security Agency )


12.

IDEA

: International Data Encryption Algorithm

: Algorithme de chiffre
ment par bloc
post DES.


13.

RSA

: Rivest Shamir et Adelman

: Algorithme d‘échange de clés.


14.

CDC

: centre de distribution des clés, intermédiaire «

de confiance

» permettant la
diffusion de clés secrètes lors de l’authentification de chacun des interlocuteurs
.


15.

SHA

: Secure Hash Algorithm

: Algorithme de hachage développé par la NSA


16.

MD5

: Algorithme développé par Rivest pour la signature numérique à l’aide de résumés
de messages.


17.

PGP

: Pretty Good Privacy (traduction

: bonne confidentialité)

: programme d
e protection
du courrier électronique


18.

SCSSI

: Service Central de la Sécurité des Systèmes d’Information

; service français qui
dépend du Premier ministre. Organisme chargé de recueillir les demandes d’autorisation
Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

28
/
36

et les déclarations d’utilisation ou de c
ommercialisation de logiciel de cryptage utilisant
une clé supérieure à 40 bits.


19.

S
-
HTTP

: Secure HTTP

: extension du protocole HTTP

: négociation de processus de
cryptage


20.

SSL

: Secure Socket Layer

: protocole de transmission sécurisée de données


21.

SET

:
Secure Electronic Transaction System, logiciel développé par Visa & Mastercard
pour éliminer les problèmes de transaction avec les cartes de crédit, et s’appuyant sur le
protocole SSL


22.

Clé

: ensemble d’informations gérées par le logiciel de cryptographie p
our permettre de
crypter ou décrypter des données. La taille des clés est donnée en bits (en général de 40 à
128 bits).


23.

LDAP

: Lightweight Directory Access Protocol est le protocole d'annuaire sur TCP/IP.
Les annuaires permettent de partager des bases d'
informations sur le réseau interne ou
externe. Ces bases peuvent contenir toute sorte d'information que ce soit des coordonnées
de personnes ou des données systèmes.


24.

B2B

: Business to Business, tout flux commercial, financier inter entreprises.


25.

B2C

: Bus
iness to consumer, tout flux commercial, financier entre particulier et
entreprises.







Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

29
/
36


Bibliographie


Le livre de Bernard Fabrot "Anonymat et Sécurité" aux éditions Marabout permet à un novice
de comprendre les bases du chiffrement.


"Sécurité et In
ternet" de Solange Ghernaouti
-
Hélie aux éditions Dunod, et "Sécurité et
Protection" de Wolfram Gieseke aux éditions Micro Applications, permettent un
approfondissement des explications sur le chiffrement, les Algorithmes DES, RSA.


"Les Réseaux" de Guy Pu
jolle aux éditions Eyrolles offre une légère explication sur le
fonctionnement de Kerberos.


"Réseaux" de Andrew Tanenbaum aux éditions Dunod est en revanche beaucoup plus dense
et permet une approche beaucoup plus complète sur la sécurité.


Introduction

to SSL, Netscape Communications Corporation

http://developer.netscape.com/docs/manuals/security/sslin/contents.htm

Le site des concepteurs, décrit très précisément
le protocole SSL. Principal support Pour
le

paragraphe SSL.


Le site du LASEC , Security and Cryptography Laboratory

http://lasecwww.epfl.ch

un site consacré à la sécurité et au cryptage ave
c des articles très récents, pertinents et
critiques. Un des articles est consacré à une faiblesse du protocole SSL.


Pour avoir une première approche des techniques de sécurisation, le lien suivant

:

http://www.commentcamarche.net/crypto


Un bon article de vulgarisation qui résume bien le problème du paiement sur Internet, sur un
site consacré à la sécurité en général.

http:
//www.secuser.com/dossiers/securite_paiements.htm


Une définition de la signature numérique et son contexte réglementaire (en France) sur le site
gouvernemental suivant

http://w
ww.internet.gouv.fr/francais/textesref/signnum.htm


Les chiffres du e
-
commerce en France (2000)

http://www.idc.fr/presse/cp_ecommerce2000.htm


L’ étude "E
-
commerce, sécurité et confiance"

(mai 2001) sur le site suivant

:

http://www.projetweb.com

Cette étude concerne les sites français. Elle ne contient pas uniquement des chiffres, elle
délivre aussi quelques analyses pertinentes.


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

30
/
36

Documents


*****************L’offre Certplus******************


Certplus

?

Créé en 1998 par quatre
actionnaires fondateurs
, Gemplus, France Telecom, EADS
(Aérospatiale Matra) et VeriSign, rejoints
début 2000 par la CIBP (Confédération
Internationale des Banques Populaires), Certplus est le premier opérateur français de services
de confiance.


Quoi

?

Certificat Serveur

Le passeport des entreprises sur Internet



Pour offrir le meilleur service à vos
clients et utilisateurs de votre site web, vous devez
garantir une confiance maximale dans l'utilisation de vos services.


Vous devez en particulier garantir :

• Que les visiteurs sont bien sur votre site web,

• Que les échanges de données sensibles (donn
ées personnelles, numéros de cartes bancaires,
login/password) sont protégés par du chiffrement.


Certplus, grâce à ses services de sécurisation web et au Certificat Serveur vous permet d'offrir
le site le plus sécurisé possible.

Vous pouvez désormais ut
iliser le
Certificat Serveur Global

qui permet un chiffrement d'une
force maximale.




Certificat Serveur Standard


Certificat Serveur Global






Acheter

Avoir plus d'informations

Plus de services


Acheter

Avoir plu
s d'informations

Plus de services



Services d'authentification Certplus



Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

31
/
36



Chiffrement SSL Certplus


40 bits


128 bits



Utilisation Label Certplus





Audit Gratuit Intranode





Utilisation recommandée


Serveurs de messagerie, Intranet, LDAP...


Sites des secteurs suivants : banque, assurance, santé, administrations,
vente en ligne...



Prix de l'abonnement

(1ère année)


370 € HT

au lieu de
450 € HT


Promotion

jusqu'au 31/12/2001

(soit 2427,04 FRF HT)


1150 € HT

(soit 7543,51 FRF HT)



Prix du renouvellement

(années suivantes)


370 € HT

(soit 2427,04 FRF HT)


1000 € HT

(soit 6559,57 FRF HT)


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

32
/
36


Remplacement avant 1 mois


Gra
tuit


Gratuit



Remplacement entre 1 et 6 mois


100 € HT

(soit 655,96 FRF HT)


250 € HT

(soit 1639,89 FRF HT)




***************************************************************************
****************




Certificat Serveur

Le passeport des entreprises

sur Internet


Les services Certplus :



Obtenez votre
Certificat Serveur
maintenant !



Renouvelez votre
Certificat Serveur



Révoquez votre
Certificat Serveur



Recherchez un
Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

33
/
36

Certificat Serveur



Vérifiez le statut de
votre requête



Obtenez votre Label
de Confiance Certplus



Opération : un
Certificat, un Audit



Votre site Web est devenu la meilleure vitrine de votre entreprise : il attire vos clients, vos
fournisseurs ou vos partenaires. Mais quelle confiance vos visiteurs lui accordent
-
ils vraiment
?


Le cer
tificat numérique d'un serveur qui héberge une page web est la carte d'identité
électronique de cette page web : il permet d'établir avec certitude le lien entre la page web
hébergée (un nom de domaine ou URL) et son propriétaire (une entreprise, un marcha
nd, un
individu), d'authentifier ce serveur et de sécuriser les échanges électroniques entre ce serveur
et les individus qui s'y connectent via Internet.

Le Certificat Serveur permet d'instaurer la confiance en authentifiant votre site et en chiffrant
l'en
semble des informations (personnelles, bancaires, etc.) entre ce site et la personne qui s'y
connecte, afin de garantir la confidentialité des échanges.

Les personnes venant visiter votre site Internet pourront formellement vous authentifier et
laisser en
toute sécurité et confiance leur numéro de carte bancaire ainsi que des informations
personnelles. Ce Certificat Serveur permet en outre de sécuriser les transactions en ligne :
vous êtes sûr que les informations données par le client ne peuvent pas être i
nterceptées,
détournées ou déchiffrées par une autre personne.


L'offre de Certplus est de vous fournir vos Certificats Serveur reconnus par l'ensemble des
internautes. Certplus, unique représentant français du Verisign Trust Network, vous propose
un servi
ce d'émission de proximité et de qualité en toute sécurité.


La délivrance par Certplus d'un Certificat Serveur du Verisign Trust Network vous permettra,
comme à plus de 150000 sites Internet dans le monde, d'établir cet "environnement de
confiance" entre
vos clients et vous, en leur permettant d'authentifier votre site et de protéger
les informations échangées entre eux et vous.


En vous appuyant sur les services de Certplus, vous pouvez, dès maintenant, activer très
Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

34
/
36

facilement un Certificat Serveur. Ce qu
i vous permettra de sécuriser vos transactions et vos
communications en utilisant des technologies standards (protocole SSL
-

Secure Socket
Layer).
Pour commander votre c
ertificat serveur, cliquez ici
.




Sur un plan technique, les identifications numériques ou certificats numériques permettent
d'associe
r une clé publique à son véritable propriétaire (le site Internet visité). La clé publique
du site permet de chiffrer les informations transmises entre le client et ce site Internet. Elle
permet également, via un module de contrôle d'intégrité inclus dans
les fonctions de
chiffrement, de vérifier que le message n'a pas été modifié au cours de son passage sur
Internet.

Un Certificat Serveur est délivré par une tierce partie de confiance, appelée Autorité de
Certification (AC). L'Autorité de Certification agi
t en quelque sorte comme une Préfecture ou
une Mairie qui délivre des cartes d'identité. L'Autorité de Certification engage une série de
vérifications selon des règles très strictes, afin d'établir avec certitude l'identité de l'entreprise
et du serveur we
b. Elle émet alors le Certificat Serveur et le retourne à l'administrateur du site
web certifié.



Le Certificat Serveur contient les informations suivantes :



Le nom du domaine à certifier (ex : www.societe.fr)



Les coordonnées de l'entreprise



La clé

publique de l'entreprise (qui permet d'activer les fonctions de
chiffrement)



Le nom de l'Autorité de Certification qui émet ce passeport électronique
(Verisign Trust Network)



La date d'expiration du Certificat Serveur



La signature de l'Autorité de C
ertification


Caractéristiques techniques :




Compatible avec plus de 50 plate
-
formes dont Microsoft, Netscape, Apache...



Compatible avec les navigateurs courants du marché



Compatible X509v3



Certification de clés RSA de 512 à 1024 bits



Permet le
s sessions SSL jusqu'a 128 bits (selon les logiciels et la
réglementation en vigueur)


Comment obtenir votre Certificat Serveur ?


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

35
/
36

P
our commander votre Certificat Serveur, il vous suffit de
cliquer ici

et de suivre les
différentes étapes.


L
ors de votre demande de Certificat Serveur, vous devrez nous présenter :



La copie des informations disponibles auprès d'InterNIC ou AFNIC (nous
fournissant la preuve que vous êtes
propriétaire du nom de domaine à certifier)



Votre numéro de SIREN


L
e Service Client contactera votre société par téléphone afin de vérifier la véracité des
informations fournies (identité de votre entreprise et de votre serveur web). Cette procédure,
c
onforme à nos "Pratiques de Certification" est, pour vous et vos clients, la garantie d'une
authentification extrêmement fiable.

Votre Certificat Serveur vous sera alors transmis et vous donnera, ainsi qu'à vos clients, les
assurances suivantes :



La pre
uve de votre identité : Certplus délivre pour votre site Internet un
passeport électronique unique, assurant à vos clients l'authenticité de votre site,
permettant le chiffrement et garantissant ainsi la confidentialité de vos
communications.



Une forte s
écurité : reposant sur le modèle de chiffrement à "Clés Publiques",
dérivé des technologies militaires, les Certificats Serveur Certplus procurent un
très haut niveau de sécurité. La technologie de chiffrement SSL étant déjà sur
votre serveur, la seule cho
se à faire pour vous est de vous procurer votre
Certificat Serveur.



Une utilisation simple : vous avez juste à vous enregistrer sur notre site pour
obtenir votre Certificat Serveur. Vos clients, eux, n'ont rien à faire. Nos
certificats Certplus, membre d
u Verisign Trust Network, sont reconnus par
tous les navigateurs courants dans le monde entier.

**********************************************************************

Certificat Serveur Global

Le passeport pour une sécurité maximale sur Internet



Grâce a
u Certificat Serveur Global, offrez à vos clients une sécurité maximale !

Les services Certplus :



Obtenez votre Certificat
Serveur maintenant !



Renouvelez votre Certificat

Serveur


Architecture et Solutions sécurisées pour l’e
-
commerce

Romain COMBET


Jean
-
Luc NALLET

36
/
36


Révoquez votre Certificat
Serveur



Recherchez un Certificat
Serveur



Vérifiez le statut de votre
requête



Obtenez votre Label de
Confiance Certplus



Opération : un Certificat, un
Audit



L
e Certificat Serveur Global permet d'effectuer un
chiffrement 128 bits

avec quasiment

tous
les navigateurs du marché.

C
e certificat vous permet d'offrir :



Un chiffrement fort avec quasiment toutes les versions export des navigateurs
(celles utilisées hors des US) de Navigator de Netscape et Explorer de
Microsoft.



Preuve de l'identité
des sites : Certplus émet un Certificat Serveur unique, qui
garantit à vos visiteurs qu'ils sont sur le bon site.



Facilité d'utilisation : votre serveur web supporte déjà les sessions SSL et les
navigateurs peuvent assurer des sessions fortes grâce au Ce
rtificat Serveur
Global. Vous devez simplement faire votre requête auprès de Certplus,
installer votre Certificat Serveur Global et vous êtes prêt !


Le Certificat Serveur Global est compatible avec tous les logiciels serveurs capables de
générer des clés

RSA de 1024 bits.