Pour simplifier, c'est un client qui s'adresse à un serveur. Je pense à un
truc simple. Pour une méthode d'authentification, une procédure à la
Bluetooth me semble être très efficcae. La partie privée (que l'on peut
voir
comme clé privée) du module peut très bien être l'adresse IP ou MAC, à
priori unique. Bon, ensuite, un bon générateur aléatoire, des algos de
chiffrement pas trop pénalisants en temps de calcul et ça peut rouler.
Pour simplifier, c'est un client qui s'adresse à un serveur. Je pense à un
truc simple. Pour une méthode d'authentification, une procédure à la
Bluetooth me semble être très efficcae. La partie privée (que l'on peut
voir
comme clé privée) du module peut très bien être l'adresse IP ou MAC, à
priori unique. Bon, ensuite, un bon générateur aléatoire, des algos de
chiffrement pas trop pénalisants en temps de calcul et ça peut rouler.
Pour simplifier, c'est un client qui s'adresse à un serveur. Je pense à un
truc simple. Pour une méthode d'authentification, une procédure à la
Bluetooth me semble être très efficcae. La partie privée (que l'on peut
voir
comme clé privée) du module peut très bien être l'adresse IP ou MAC, à
priori unique. Bon, ensuite, un bon générateur aléatoire, des algos de
chiffrement pas trop pénalisants en temps de calcul et ça peut rouler.
En l'occurrence lorsque tu parles de clients qui s'adressent à un
serveur, la problématique n'est pas la même selon que le client est
un PIC au bout d'un réseau de terrain ou un PC sur un réseau local.
Par contre si
ton client est capable d'exécuter un Blowfish CBC (ou un 3DES, ou ce
que tu veux d'autre) sans impact sur tes performances, tu peux mettre
en place une authentification mutuelle en 3 passes (et en 2 coups de
cuiller à pot) :
0) le client A et le serveur B disposent d'une clé Kab (stockée
proprement...)
1) A génère un aléas Ra (8 octets), et envoie C1=C(Kab, Ra)
2) B retrouve Ra=D(Kab, C1), calcule Ra' (une transformation "simple"
de Ra comme un décalage d'un octet dans un sens ou dans l'autre),
génère l'aléas Rb (8 octets), et envoie la concaténation de C2=C(Kab,
Ra') et C3=C(Kab, Rb) 3) A retrouve Ra'=D(Kab, C2) et vérifie ainsi
que B est authentique. A retrouve également Rb=D(Kab, C3), calcule
Rb', et envoie C4=C(Kab, Rb') 4) B retrouve Rb'=D(Kab, C4) et vérifie
ainsi que A est authentique 5) A et B dialoguent en chiffrement CBC
en utilisant la concaténation de Ra et de Rb (16 octets) comme clé de
session Ks [1].
Maintenant comme ton soucis semble bien être d'authentifier
individuellement chaque client,
il faut que la clé Kab soit propre à
A et à B.
"Il suffit" alors de partir d'une clé racine commune à tous
tes modules Kr, et de définir Kab=C(Kr, numéro de série de A ||
numéro de série de B). Côté serveur tu peux ainsi te contenter de
stocker Kr (et de bien la protéger)
et recalculer Kab à chaque
ouverture de session, côté client tu peux ne stocker que Kab et
éviter ainsi la compromission de l'ensemble en cas d'attaque réussie
sur le client... Bon, maintenant cela n'empêche pas d'avoir une Kr
qui varie avec le mois dans l'année, la plage d'adresse IP, la phase
de la lune ou l'âge du capitaine, mais l'idée est là.
[1] Petite optimisation, une fois la clé de session établie tu peux
utiliser un chiffrement à sens unique : par exemple lors d'un envoi
de A vers B, la trame transmise est C(Ks, xxx), et lors d'un envoi de
B vers A, D(Ks, xxx). Ainsi A ne fait que Chiffrer et B ne fait que
Déchiffrer, ce qui évite d'avoir à recharger les sous-clés à chaque
tour.
En l'occurrence lorsque tu parles de clients qui s'adressent à un
serveur, la problématique n'est pas la même selon que le client est
un PIC au bout d'un réseau de terrain ou un PC sur un réseau local.
Par contre si
ton client est capable d'exécuter un Blowfish CBC (ou un 3DES, ou ce
que tu veux d'autre) sans impact sur tes performances, tu peux mettre
en place une authentification mutuelle en 3 passes (et en 2 coups de
cuiller à pot) :
0) le client A et le serveur B disposent d'une clé Kab (stockée
proprement...)
1) A génère un aléas Ra (8 octets), et envoie C1=C(Kab, Ra)
2) B retrouve Ra=D(Kab, C1), calcule Ra' (une transformation "simple"
de Ra comme un décalage d'un octet dans un sens ou dans l'autre),
génère l'aléas Rb (8 octets), et envoie la concaténation de C2=C(Kab,
Ra') et C3=C(Kab, Rb) 3) A retrouve Ra'=D(Kab, C2) et vérifie ainsi
que B est authentique. A retrouve également Rb=D(Kab, C3), calcule
Rb', et envoie C4=C(Kab, Rb') 4) B retrouve Rb'=D(Kab, C4) et vérifie
ainsi que A est authentique 5) A et B dialoguent en chiffrement CBC
en utilisant la concaténation de Ra et de Rb (16 octets) comme clé de
session Ks [1].
Maintenant comme ton soucis semble bien être d'authentifier
individuellement chaque client,
il faut que la clé Kab soit propre à
A et à B.
"Il suffit" alors de partir d'une clé racine commune à tous
tes modules Kr, et de définir Kab=C(Kr, numéro de série de A ||
numéro de série de B). Côté serveur tu peux ainsi te contenter de
stocker Kr (et de bien la protéger)
et recalculer Kab à chaque
ouverture de session, côté client tu peux ne stocker que Kab et
éviter ainsi la compromission de l'ensemble en cas d'attaque réussie
sur le client... Bon, maintenant cela n'empêche pas d'avoir une Kr
qui varie avec le mois dans l'année, la plage d'adresse IP, la phase
de la lune ou l'âge du capitaine, mais l'idée est là.
[1] Petite optimisation, une fois la clé de session établie tu peux
utiliser un chiffrement à sens unique : par exemple lors d'un envoi
de A vers B, la trame transmise est C(Ks, xxx), et lors d'un envoi de
B vers A, D(Ks, xxx). Ainsi A ne fait que Chiffrer et B ne fait que
Déchiffrer, ce qui évite d'avoir à recharger les sous-clés à chaque
tour.
En l'occurrence lorsque tu parles de clients qui s'adressent à un
serveur, la problématique n'est pas la même selon que le client est
un PIC au bout d'un réseau de terrain ou un PC sur un réseau local.
Par contre si
ton client est capable d'exécuter un Blowfish CBC (ou un 3DES, ou ce
que tu veux d'autre) sans impact sur tes performances, tu peux mettre
en place une authentification mutuelle en 3 passes (et en 2 coups de
cuiller à pot) :
0) le client A et le serveur B disposent d'une clé Kab (stockée
proprement...)
1) A génère un aléas Ra (8 octets), et envoie C1=C(Kab, Ra)
2) B retrouve Ra=D(Kab, C1), calcule Ra' (une transformation "simple"
de Ra comme un décalage d'un octet dans un sens ou dans l'autre),
génère l'aléas Rb (8 octets), et envoie la concaténation de C2=C(Kab,
Ra') et C3=C(Kab, Rb) 3) A retrouve Ra'=D(Kab, C2) et vérifie ainsi
que B est authentique. A retrouve également Rb=D(Kab, C3), calcule
Rb', et envoie C4=C(Kab, Rb') 4) B retrouve Rb'=D(Kab, C4) et vérifie
ainsi que A est authentique 5) A et B dialoguent en chiffrement CBC
en utilisant la concaténation de Ra et de Rb (16 octets) comme clé de
session Ks [1].
Maintenant comme ton soucis semble bien être d'authentifier
individuellement chaque client,
il faut que la clé Kab soit propre à
A et à B.
"Il suffit" alors de partir d'une clé racine commune à tous
tes modules Kr, et de définir Kab=C(Kr, numéro de série de A ||
numéro de série de B). Côté serveur tu peux ainsi te contenter de
stocker Kr (et de bien la protéger)
et recalculer Kab à chaque
ouverture de session, côté client tu peux ne stocker que Kab et
éviter ainsi la compromission de l'ensemble en cas d'attaque réussie
sur le client... Bon, maintenant cela n'empêche pas d'avoir une Kr
qui varie avec le mois dans l'année, la plage d'adresse IP, la phase
de la lune ou l'âge du capitaine, mais l'idée est là.
[1] Petite optimisation, une fois la clé de session établie tu peux
utiliser un chiffrement à sens unique : par exemple lors d'un envoi
de A vers B, la trame transmise est C(Ks, xxx), et lors d'un envoi de
B vers A, D(Ks, xxx). Ainsi A ne fait que Chiffrer et B ne fait que
Déchiffrer, ce qui évite d'avoir à recharger les sous-clés à chaque
tour.
C'est déjà un problème ! En tant que vieux reverseur, j'ai craqué
tellement
de trucs basés sur des paramètres privés, que je doute un peu de ce
principe
:-). Ou alors, une autre forme de clé privée, comme je disais plus haut.
Un
paramètre secret (qui permet d'identifier donc), mais qui peut changer
suivant les clients (comme une adresse IP), ce qui permet de ne pas
compromettre tous les clients si UNE clé privée est découverte. Quand je
dis
adresse IP, comprendre "basé" sur l'adresse IP, pas l'adresse IP toute
seule
bien évidemment.
1) A génère un aléas Ra (8 octets), et envoie C1=C(Kab, Ra)
Jusque là, ça va :-). Mais je me méfie quand même des protocoles à
plusieurs
échanges. Je veux dire, une attaque "simple" est toujours faisable (j'ai
déjà pratiqué, je peux témoigner). Pour simplifier, je me place entre A et
B
et intercepte tout ce qui passe. Pour les phases d'authentification, ce
n'est généralement pas compliqué à déceler, ce ne sont que quelques octets
et, souvent, certains sont redondants entre les premiers échanges. Les
transactions elles, occuppent des paquets plus importants. Bref, il m'est
arrivé de n'avoir qu'à reproduire les paquets "devinés" d'authentification
pour pouvoir me faire passer comme correct et déclencher une session. Il
faut donc que ce genre de méthode soit élaborée avec une certaine
précaution
dirai-je...
2) B retrouve Ra=D(Kab, C1), calcule Ra' (une transformation "simple"
de Ra comme un décalage d'un octet dans un sens ou dans l'autre),
génère l'aléas Rb (8 octets), et envoie la concaténation de C2=C(Kab,
Ra') et C3=C(Kab, Rb) 3) A retrouve Ra'=D(Kab, C2) et vérifie ainsi
que B est authentique. A retrouve également Rb=D(Kab, C3), calcule
Rb', et envoie C4=C(Kab, Rb') 4) B retrouve Rb'=D(Kab, C4) et vérifie
ainsi que A est authentique 5) A et B dialoguent en chiffrement CBC
en utilisant la concaténation de Ra et de Rb (16 octets) comme clé de
session Ks [1].
Moui. Cela me semble correct. Sauf que j'agrandirai un peut certaines
tailles sans doute. 8 octets c'est assez bruteforçable quand même.
Maintenant comme ton soucis semble bien être d'authentifier
individuellement chaque client,
C'est le hic.il faut que la clé Kab soit propre à
A et à B.
C'est sur ce que je bute :-)."Il suffit" alors de partir d'une clé racine commune à tous
tes modules Kr, et de définir Kab=C(Kr, numéro de série de A ||
numéro de série de B). Côté serveur tu peux ainsi te contenter de
stocker Kr (et de bien la protéger)
Un serveur est en général en milieu sécurisé, donc difficilement
reversable,
hackable, etc. Enfin, en général :-). C'est du côté client qu'il faut
trouver une méthode imparable, les clients sont eux, en général, en milieu
heu "hostile".
et recalculer Kab à chaque
ouverture de session, côté client tu peux ne stocker que Kab et
éviter ainsi la compromission de l'ensemble en cas d'attaque réussie
sur le client... Bon, maintenant cela n'empêche pas d'avoir une Kr
qui varie avec le mois dans l'année, la plage d'adresse IP, la phase
de la lune ou l'âge du capitaine, mais l'idée est là.
Oui, Kr est un peu le code PIN en Bluetooth, souvent a zéro et que tu peux
changer quand tu veux, si j'ai bien compris.
[1] Petite optimisation, une fois la clé de session établie tu peux
utiliser un chiffrement à sens unique : par exemple lors d'un envoi
de A vers B, la trame transmise est C(Ks, xxx), et lors d'un envoi de
B vers A, D(Ks, xxx). Ainsi A ne fait que Chiffrer et B ne fait que
Déchiffrer, ce qui évite d'avoir à recharger les sous-clés à chaque
tour.
Oui, c'est un autre problème cela. Chiffrer/déchiffrer à chaque
transaction
? Authentifier à chaque transaction ? Conserver la clé de session pendant
X
temps ? Etc. Tout cela étant gourmand en ressource, si simplification il y
a, c'est bienvenu.
Sinon, merci pour tes suggestions. Je vais relire tout ça tranquilement.
Je
ne m'étais jamais réellement penché sur ce problème
d'authentification/signature/certification/etc auparavant (je veux dire,
au
niveau code) et ai soigneusement évité de lire tout post à ce sujet
jusqu'ici :-). En fait, je suis assez circonspect. Depuis quelques jours,
je
potasse un peu de littérature sur le sujet, dont l'excellent bouquin de
William Stallings, Cryptography and Network Security, qui traite de la
chose
en long, en large et en travers et je me demande s'il y a une solution !
Je
veux dire, je viens de terminer les Hashes, les MACs, les authentification
a
clés privées, à clés privées/publiques, etc. or, tout est soumis à
tellement
de restrictions, tout est (dans une certaine mesure) tellement
comprometable, que je me demande si ce problème est résolvable de manière
sûre ! Enfin bon, il me reste encore le chapitre sur les signatures
numériques et les protocoles d'authentification à finir, mais bon, I'm
scratching my head, je me dis que tout cela est un boulot considérable
pour
pas grand-chose au final... Mais c'est égal, le livre de Stalling est
vraiment excellent.
C'est déjà un problème ! En tant que vieux reverseur, j'ai craqué
tellement
de trucs basés sur des paramètres privés, que je doute un peu de ce
principe
:-). Ou alors, une autre forme de clé privée, comme je disais plus haut.
Un
paramètre secret (qui permet d'identifier donc), mais qui peut changer
suivant les clients (comme une adresse IP), ce qui permet de ne pas
compromettre tous les clients si UNE clé privée est découverte. Quand je
dis
adresse IP, comprendre "basé" sur l'adresse IP, pas l'adresse IP toute
seule
bien évidemment.
1) A génère un aléas Ra (8 octets), et envoie C1=C(Kab, Ra)
Jusque là, ça va :-). Mais je me méfie quand même des protocoles à
plusieurs
échanges. Je veux dire, une attaque "simple" est toujours faisable (j'ai
déjà pratiqué, je peux témoigner). Pour simplifier, je me place entre A et
B
et intercepte tout ce qui passe. Pour les phases d'authentification, ce
n'est généralement pas compliqué à déceler, ce ne sont que quelques octets
et, souvent, certains sont redondants entre les premiers échanges. Les
transactions elles, occuppent des paquets plus importants. Bref, il m'est
arrivé de n'avoir qu'à reproduire les paquets "devinés" d'authentification
pour pouvoir me faire passer comme correct et déclencher une session. Il
faut donc que ce genre de méthode soit élaborée avec une certaine
précaution
dirai-je...
2) B retrouve Ra=D(Kab, C1), calcule Ra' (une transformation "simple"
de Ra comme un décalage d'un octet dans un sens ou dans l'autre),
génère l'aléas Rb (8 octets), et envoie la concaténation de C2=C(Kab,
Ra') et C3=C(Kab, Rb) 3) A retrouve Ra'=D(Kab, C2) et vérifie ainsi
que B est authentique. A retrouve également Rb=D(Kab, C3), calcule
Rb', et envoie C4=C(Kab, Rb') 4) B retrouve Rb'=D(Kab, C4) et vérifie
ainsi que A est authentique 5) A et B dialoguent en chiffrement CBC
en utilisant la concaténation de Ra et de Rb (16 octets) comme clé de
session Ks [1].
Moui. Cela me semble correct. Sauf que j'agrandirai un peut certaines
tailles sans doute. 8 octets c'est assez bruteforçable quand même.
Maintenant comme ton soucis semble bien être d'authentifier
individuellement chaque client,
C'est le hic.
il faut que la clé Kab soit propre à
A et à B.
C'est sur ce que je bute :-).
"Il suffit" alors de partir d'une clé racine commune à tous
tes modules Kr, et de définir Kab=C(Kr, numéro de série de A ||
numéro de série de B). Côté serveur tu peux ainsi te contenter de
stocker Kr (et de bien la protéger)
Un serveur est en général en milieu sécurisé, donc difficilement
reversable,
hackable, etc. Enfin, en général :-). C'est du côté client qu'il faut
trouver une méthode imparable, les clients sont eux, en général, en milieu
heu "hostile".
et recalculer Kab à chaque
ouverture de session, côté client tu peux ne stocker que Kab et
éviter ainsi la compromission de l'ensemble en cas d'attaque réussie
sur le client... Bon, maintenant cela n'empêche pas d'avoir une Kr
qui varie avec le mois dans l'année, la plage d'adresse IP, la phase
de la lune ou l'âge du capitaine, mais l'idée est là.
Oui, Kr est un peu le code PIN en Bluetooth, souvent a zéro et que tu peux
changer quand tu veux, si j'ai bien compris.
[1] Petite optimisation, une fois la clé de session établie tu peux
utiliser un chiffrement à sens unique : par exemple lors d'un envoi
de A vers B, la trame transmise est C(Ks, xxx), et lors d'un envoi de
B vers A, D(Ks, xxx). Ainsi A ne fait que Chiffrer et B ne fait que
Déchiffrer, ce qui évite d'avoir à recharger les sous-clés à chaque
tour.
Oui, c'est un autre problème cela. Chiffrer/déchiffrer à chaque
transaction
? Authentifier à chaque transaction ? Conserver la clé de session pendant
X
temps ? Etc. Tout cela étant gourmand en ressource, si simplification il y
a, c'est bienvenu.
Sinon, merci pour tes suggestions. Je vais relire tout ça tranquilement.
Je
ne m'étais jamais réellement penché sur ce problème
d'authentification/signature/certification/etc auparavant (je veux dire,
au
niveau code) et ai soigneusement évité de lire tout post à ce sujet
jusqu'ici :-). En fait, je suis assez circonspect. Depuis quelques jours,
je
potasse un peu de littérature sur le sujet, dont l'excellent bouquin de
William Stallings, Cryptography and Network Security, qui traite de la
chose
en long, en large et en travers et je me demande s'il y a une solution !
Je
veux dire, je viens de terminer les Hashes, les MACs, les authentification
a
clés privées, à clés privées/publiques, etc. or, tout est soumis à
tellement
de restrictions, tout est (dans une certaine mesure) tellement
comprometable, que je me demande si ce problème est résolvable de manière
sûre ! Enfin bon, il me reste encore le chapitre sur les signatures
numériques et les protocoles d'authentification à finir, mais bon, I'm
scratching my head, je me dis que tout cela est un boulot considérable
pour
pas grand-chose au final... Mais c'est égal, le livre de Stalling est
vraiment excellent.
C'est déjà un problème ! En tant que vieux reverseur, j'ai craqué
tellement
de trucs basés sur des paramètres privés, que je doute un peu de ce
principe
:-). Ou alors, une autre forme de clé privée, comme je disais plus haut.
Un
paramètre secret (qui permet d'identifier donc), mais qui peut changer
suivant les clients (comme une adresse IP), ce qui permet de ne pas
compromettre tous les clients si UNE clé privée est découverte. Quand je
dis
adresse IP, comprendre "basé" sur l'adresse IP, pas l'adresse IP toute
seule
bien évidemment.
1) A génère un aléas Ra (8 octets), et envoie C1=C(Kab, Ra)
Jusque là, ça va :-). Mais je me méfie quand même des protocoles à
plusieurs
échanges. Je veux dire, une attaque "simple" est toujours faisable (j'ai
déjà pratiqué, je peux témoigner). Pour simplifier, je me place entre A et
B
et intercepte tout ce qui passe. Pour les phases d'authentification, ce
n'est généralement pas compliqué à déceler, ce ne sont que quelques octets
et, souvent, certains sont redondants entre les premiers échanges. Les
transactions elles, occuppent des paquets plus importants. Bref, il m'est
arrivé de n'avoir qu'à reproduire les paquets "devinés" d'authentification
pour pouvoir me faire passer comme correct et déclencher une session. Il
faut donc que ce genre de méthode soit élaborée avec une certaine
précaution
dirai-je...
2) B retrouve Ra=D(Kab, C1), calcule Ra' (une transformation "simple"
de Ra comme un décalage d'un octet dans un sens ou dans l'autre),
génère l'aléas Rb (8 octets), et envoie la concaténation de C2=C(Kab,
Ra') et C3=C(Kab, Rb) 3) A retrouve Ra'=D(Kab, C2) et vérifie ainsi
que B est authentique. A retrouve également Rb=D(Kab, C3), calcule
Rb', et envoie C4=C(Kab, Rb') 4) B retrouve Rb'=D(Kab, C4) et vérifie
ainsi que A est authentique 5) A et B dialoguent en chiffrement CBC
en utilisant la concaténation de Ra et de Rb (16 octets) comme clé de
session Ks [1].
Moui. Cela me semble correct. Sauf que j'agrandirai un peut certaines
tailles sans doute. 8 octets c'est assez bruteforçable quand même.
Maintenant comme ton soucis semble bien être d'authentifier
individuellement chaque client,
C'est le hic.il faut que la clé Kab soit propre à
A et à B.
C'est sur ce que je bute :-)."Il suffit" alors de partir d'une clé racine commune à tous
tes modules Kr, et de définir Kab=C(Kr, numéro de série de A ||
numéro de série de B). Côté serveur tu peux ainsi te contenter de
stocker Kr (et de bien la protéger)
Un serveur est en général en milieu sécurisé, donc difficilement
reversable,
hackable, etc. Enfin, en général :-). C'est du côté client qu'il faut
trouver une méthode imparable, les clients sont eux, en général, en milieu
heu "hostile".
et recalculer Kab à chaque
ouverture de session, côté client tu peux ne stocker que Kab et
éviter ainsi la compromission de l'ensemble en cas d'attaque réussie
sur le client... Bon, maintenant cela n'empêche pas d'avoir une Kr
qui varie avec le mois dans l'année, la plage d'adresse IP, la phase
de la lune ou l'âge du capitaine, mais l'idée est là.
Oui, Kr est un peu le code PIN en Bluetooth, souvent a zéro et que tu peux
changer quand tu veux, si j'ai bien compris.
[1] Petite optimisation, une fois la clé de session établie tu peux
utiliser un chiffrement à sens unique : par exemple lors d'un envoi
de A vers B, la trame transmise est C(Ks, xxx), et lors d'un envoi de
B vers A, D(Ks, xxx). Ainsi A ne fait que Chiffrer et B ne fait que
Déchiffrer, ce qui évite d'avoir à recharger les sous-clés à chaque
tour.
Oui, c'est un autre problème cela. Chiffrer/déchiffrer à chaque
transaction
? Authentifier à chaque transaction ? Conserver la clé de session pendant
X
temps ? Etc. Tout cela étant gourmand en ressource, si simplification il y
a, c'est bienvenu.
Sinon, merci pour tes suggestions. Je vais relire tout ça tranquilement.
Je
ne m'étais jamais réellement penché sur ce problème
d'authentification/signature/certification/etc auparavant (je veux dire,
au
niveau code) et ai soigneusement évité de lire tout post à ce sujet
jusqu'ici :-). En fait, je suis assez circonspect. Depuis quelques jours,
je
potasse un peu de littérature sur le sujet, dont l'excellent bouquin de
William Stallings, Cryptography and Network Security, qui traite de la
chose
en long, en large et en travers et je me demande s'il y a une solution !
Je
veux dire, je viens de terminer les Hashes, les MACs, les authentification
a
clés privées, à clés privées/publiques, etc. or, tout est soumis à
tellement
de restrictions, tout est (dans une certaine mesure) tellement
comprometable, que je me demande si ce problème est résolvable de manière
sûre ! Enfin bon, il me reste encore le chapitre sur les signatures
numériques et les protocoles d'authentification à finir, mais bon, I'm
scratching my head, je me dis que tout cela est un boulot considérable
pour
pas grand-chose au final... Mais c'est égal, le livre de Stalling est
vraiment excellent.
Les clients sont des PCs. La puissance de calcul n'est donc pas pénalisante,
mais, pour autant, il peut y avoir beaucoup de transactions, il ne faut donc
pas que les procédures d'authentifications soient longues.
Les clients sont des PCs. La puissance de calcul n'est donc pas pénalisante,
mais, pour autant, il peut y avoir beaucoup de transactions, il ne faut donc
pas que les procédures d'authentifications soient longues.
Les clients sont des PCs. La puissance de calcul n'est donc pas pénalisante,
mais, pour autant, il peut y avoir beaucoup de transactions, il ne faut donc
pas que les procédures d'authentifications soient longues.
