Tu as une idée du temps de transaction ?
Tu as une idée du temps de transaction ?
Tu as une idée du temps de transaction ?
concernant la puce:
Erwann ABALEA wrote on 15/04/2006 15:47:On Fri, 14 Apr 2006, Philippe Martin wrote:N'ayant suivi ce project que de très loin, et si l'info est publique: je
crois comprendre que la puce n'est en fait qu'une carte mémoire RF et
qu'il n'existe aucune authentification avec le terminal -
tout le contraire.
[...]
auth. avec une signature ISO9796-2 - la clé publique de ce biclé est bien sur
utilisé dans l'input du SOD.
Les docs disponibles librement (www.icao.int) semblent dire qu'en effet,
c'est une simple mémoire. Mais on peut mettre des informations chiffrées,
dans cette mémoire.
les specs n'obligent pas la présence des éléments décrits ci-avant, le
passport US est "aussi conforme" ICAO que le passport européen.
Erwann ABALEA wrote on 15/04/2006 13:03:On Sat, 15 Apr 2006, Fred wrote:
[..]un passeport une fois personnalisé n'est plus modifiable, tout
au plus clonable (avec la même photo, et le même état-civil dans la
puce), donc pas grand intérêt.
donc pas vraiment, il [la puce] n'est pas clonable (on ne relit pas le
biclé).
concernant les prestataires:On Fri, 14 Apr 2006, Sylvain wrote:pour rester au niveau d'info. publique, il semble que le
quasi-blocage du système de télé-déclaration de l'IR
l'automne dernier a laissé qlq (mauvais) souvenirs
(pour parler de l'IGC, un peu en rapport avec la chartre)
Ben justement, non, au contraire. Je ne sais pas ce que je peux dire
publiquement, aussi je resterai vague, mais nous avons été
favorablement accueillis, attendus, demandés (avec le même genre de
soutien dont tu faisais mention plus haut).
"nous" ? Erwann serait dans la partie ? ;)
Keynectis a surement été demandé, attendu, ..., par Thalès - chef
d'orchestre, mais il me semble bien que le ministère voulait quelqu'un
d'autre.
je ne travaille ni pour l'un, ni pour l'autre, j'essaie donc de considérer ce
point avec recul et pragmatisme, dans cet exercice je m'interroge sur la
nécéssité d'avoir un seul et unique fournisseur PKI pour l'Etat (je ne ferais
au final, il reste étonnant
que le ministère (client final) ne puisse pas choisir son système (les 2
offres étaient différentes quant à leur contenu, à tout le moins sur les
modalités de mise en oeuvre).
D'ailleurs, le dit blocage de l'IR de l'automne (automne? donc
hors période de déclaration?) ne concernait pas l'IGC (enfin
son fournisseur).
ok pour la saison, c'en était une autre.
pour le reste tu bottes un peu vite en touche; quand la DCSSI (ou un
ministère) demande la fourniture d'un système, i ne fournit a peu près que la
prise installer le matériel requis;
si le système sature, je crains que le
fournisseur ait sa part de responsabilité sur le dimensionnement du système
et/ou les recommendations qu'il pourrait avoir oublié de faire.
concernant la puce:
Erwann ABALEA wrote on 15/04/2006 15:47:
On Fri, 14 Apr 2006, Philippe Martin wrote:
N'ayant suivi ce project que de très loin, et si l'info est publique: je
crois comprendre que la puce n'est en fait qu'une carte mémoire RF et
qu'il n'existe aucune authentification avec le terminal -
tout le contraire.
[...]
auth. avec une signature ISO9796-2 - la clé publique de ce biclé est bien sur
utilisé dans l'input du SOD.
Les docs disponibles librement (www.icao.int) semblent dire qu'en effet,
c'est une simple mémoire. Mais on peut mettre des informations chiffrées,
dans cette mémoire.
les specs n'obligent pas la présence des éléments décrits ci-avant, le
passport US est "aussi conforme" ICAO que le passport européen.
Erwann ABALEA wrote on 15/04/2006 13:03:
On Sat, 15 Apr 2006, Fred wrote:
[..]un passeport une fois personnalisé n'est plus modifiable, tout
au plus clonable (avec la même photo, et le même état-civil dans la
puce), donc pas grand intérêt.
donc pas vraiment, il [la puce] n'est pas clonable (on ne relit pas le
biclé).
concernant les prestataires:
On Fri, 14 Apr 2006, Sylvain wrote:
pour rester au niveau d'info. publique, il semble que le
quasi-blocage du système de télé-déclaration de l'IR
l'automne dernier a laissé qlq (mauvais) souvenirs
(pour parler de l'IGC, un peu en rapport avec la chartre)
Ben justement, non, au contraire. Je ne sais pas ce que je peux dire
publiquement, aussi je resterai vague, mais nous avons été
favorablement accueillis, attendus, demandés (avec le même genre de
soutien dont tu faisais mention plus haut).
"nous" ? Erwann serait dans la partie ? ;)
Keynectis a surement été demandé, attendu, ..., par Thalès - chef
d'orchestre, mais il me semble bien que le ministère voulait quelqu'un
d'autre.
je ne travaille ni pour l'un, ni pour l'autre, j'essaie donc de considérer ce
point avec recul et pragmatisme, dans cet exercice je m'interroge sur la
nécéssité d'avoir un seul et unique fournisseur PKI pour l'Etat (je ne ferais
au final, il reste étonnant
que le ministère (client final) ne puisse pas choisir son système (les 2
offres étaient différentes quant à leur contenu, à tout le moins sur les
modalités de mise en oeuvre).
D'ailleurs, le dit blocage de l'IR de l'automne (automne? donc
hors période de déclaration?) ne concernait pas l'IGC (enfin
son fournisseur).
ok pour la saison, c'en était une autre.
pour le reste tu bottes un peu vite en touche; quand la DCSSI (ou un
ministère) demande la fourniture d'un système, i ne fournit a peu près que la
prise installer le matériel requis;
si le système sature, je crains que le
fournisseur ait sa part de responsabilité sur le dimensionnement du système
et/ou les recommendations qu'il pourrait avoir oublié de faire.
concernant la puce:
Erwann ABALEA wrote on 15/04/2006 15:47:On Fri, 14 Apr 2006, Philippe Martin wrote:N'ayant suivi ce project que de très loin, et si l'info est publique: je
crois comprendre que la puce n'est en fait qu'une carte mémoire RF et
qu'il n'existe aucune authentification avec le terminal -
tout le contraire.
[...]
auth. avec une signature ISO9796-2 - la clé publique de ce biclé est bien sur
utilisé dans l'input du SOD.
Les docs disponibles librement (www.icao.int) semblent dire qu'en effet,
c'est une simple mémoire. Mais on peut mettre des informations chiffrées,
dans cette mémoire.
les specs n'obligent pas la présence des éléments décrits ci-avant, le
passport US est "aussi conforme" ICAO que le passport européen.
Erwann ABALEA wrote on 15/04/2006 13:03:On Sat, 15 Apr 2006, Fred wrote:
[..]un passeport une fois personnalisé n'est plus modifiable, tout
au plus clonable (avec la même photo, et le même état-civil dans la
puce), donc pas grand intérêt.
donc pas vraiment, il [la puce] n'est pas clonable (on ne relit pas le
biclé).
concernant les prestataires:On Fri, 14 Apr 2006, Sylvain wrote:pour rester au niveau d'info. publique, il semble que le
quasi-blocage du système de télé-déclaration de l'IR
l'automne dernier a laissé qlq (mauvais) souvenirs
(pour parler de l'IGC, un peu en rapport avec la chartre)
Ben justement, non, au contraire. Je ne sais pas ce que je peux dire
publiquement, aussi je resterai vague, mais nous avons été
favorablement accueillis, attendus, demandés (avec le même genre de
soutien dont tu faisais mention plus haut).
"nous" ? Erwann serait dans la partie ? ;)
Keynectis a surement été demandé, attendu, ..., par Thalès - chef
d'orchestre, mais il me semble bien que le ministère voulait quelqu'un
d'autre.
je ne travaille ni pour l'un, ni pour l'autre, j'essaie donc de considérer ce
point avec recul et pragmatisme, dans cet exercice je m'interroge sur la
nécéssité d'avoir un seul et unique fournisseur PKI pour l'Etat (je ne ferais
au final, il reste étonnant
que le ministère (client final) ne puisse pas choisir son système (les 2
offres étaient différentes quant à leur contenu, à tout le moins sur les
modalités de mise en oeuvre).
D'ailleurs, le dit blocage de l'IR de l'automne (automne? donc
hors période de déclaration?) ne concernait pas l'IGC (enfin
son fournisseur).
ok pour la saison, c'en était une autre.
pour le reste tu bottes un peu vite en touche; quand la DCSSI (ou un
ministère) demande la fourniture d'un système, i ne fournit a peu près que la
prise installer le matériel requis;
si le système sature, je crains que le
fournisseur ait sa part de responsabilité sur le dimensionnement du système
et/ou les recommendations qu'il pourrait avoir oublié de faire.
Philippe Martin wrote on 15/04/2006 17:11:Tu as une idée du temps de transaction ?
le temps de quelle transaction ?
une signature RSA ? entre 100 et 300 ms.
une lecture des données sous secure channel ISO ? c'est linéaire avec le
volume des données (2 à 5 sec. pour 12 à 30 ko de données).
Sylvain.
Philippe Martin wrote on 15/04/2006 17:11:
Tu as une idée du temps de transaction ?
le temps de quelle transaction ?
une signature RSA ? entre 100 et 300 ms.
une lecture des données sous secure channel ISO ? c'est linéaire avec le
volume des données (2 à 5 sec. pour 12 à 30 ko de données).
Sylvain.
Philippe Martin wrote on 15/04/2006 17:11:Tu as une idée du temps de transaction ?
le temps de quelle transaction ?
une signature RSA ? entre 100 et 300 ms.
une lecture des données sous secure channel ISO ? c'est linéaire avec le
volume des données (2 à 5 sec. pour 12 à 30 ko de données).
Sylvain.
Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à ~70000
bauds, je trouve ça balaise.
Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à ~70000
bauds, je trouve ça balaise.
Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à ~70000
bauds, je trouve ça balaise.
Philippe Martin wrote on 15/04/2006 21:39:Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à
~70000 bauds, je trouve ça balaise.
pour une communication à 414 ou 828 Kbds moi je trouve ça null.
Sylvain.
Philippe Martin wrote on 15/04/2006 21:39:
Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à
~70000 bauds, je trouve ça balaise.
pour une communication à 414 ou 828 Kbds moi je trouve ça null.
Sylvain.
Philippe Martin wrote on 15/04/2006 21:39:Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à
~70000 bauds, je trouve ça balaise.
pour une communication à 414 ou 828 Kbds moi je trouve ça null.
Sylvain.
Toutafé. En France, on en a profité pour passer directement à la puce,
tant qu'à faire.
C'est pas plus mal, si les specs sont sèches.
Tout ce que je peux dire:
- les heures sup', c'est crevant
Keynectis a surement été demandé, attendu, ..., par Thalès - chef
d'orchestre, mais il me semble bien que le ministère voulait quelqu'un
d'autre.
Presque ça. En fait, c'est le contraire ;)
Je ne sais pas si les specs ICAO autorisent un Etat à avoir plusieurs
clés racine, mais il est certain que l'Etat peut déleguer la fabrication
des passeports à plusieurs fournisseurs, y compris plusieurs
fournisseurs de PKI.
Tant que le fournisseur de PKI sait générer un PKCS#10 pour
se faire authentifier par la racine, et sait faire des
signatures telles que définies par l'ICAO, alors tout va bien.
On aurait pu imaginer que l'Etat ne génère que sa clé racine, et que
différents fournisseurs puissent la mettre en oeuvre dans des matériels
différents, mais en pratique c'est très difficile à faire proprement. La
faute aux fournisseurs de HSM.
On sort du cadre de ce newsgroup, puisque le dit blocage ne concerne
pas l'IGC, mais puisqu'on en cause...
Pour en revenir au fil initial, j'ai rapidement parcouru le site
www.icao.int, j'ai trouvé quelques docs plus ou moins techniques, mais
je retombe souvent sur leur CDROM-à-acheter-qui-contient-tout. Difficile
pour le citoyen curieux de se faire une idée de l'ensemble.
Toutafé. En France, on en a profité pour passer directement à la puce,
tant qu'à faire.
C'est pas plus mal, si les specs sont sèches.
Tout ce que je peux dire:
- les heures sup', c'est crevant
Keynectis a surement été demandé, attendu, ..., par Thalès - chef
d'orchestre, mais il me semble bien que le ministère voulait quelqu'un
d'autre.
Presque ça. En fait, c'est le contraire ;)
Je ne sais pas si les specs ICAO autorisent un Etat à avoir plusieurs
clés racine, mais il est certain que l'Etat peut déleguer la fabrication
des passeports à plusieurs fournisseurs, y compris plusieurs
fournisseurs de PKI.
Tant que le fournisseur de PKI sait générer un PKCS#10 pour
se faire authentifier par la racine, et sait faire des
signatures telles que définies par l'ICAO, alors tout va bien.
On aurait pu imaginer que l'Etat ne génère que sa clé racine, et que
différents fournisseurs puissent la mettre en oeuvre dans des matériels
différents, mais en pratique c'est très difficile à faire proprement. La
faute aux fournisseurs de HSM.
On sort du cadre de ce newsgroup, puisque le dit blocage ne concerne
pas l'IGC, mais puisqu'on en cause...
Pour en revenir au fil initial, j'ai rapidement parcouru le site
www.icao.int, j'ai trouvé quelques docs plus ou moins techniques, mais
je retombe souvent sur leur CDROM-à-acheter-qui-contient-tout. Difficile
pour le citoyen curieux de se faire une idée de l'ensemble.
Toutafé. En France, on en a profité pour passer directement à la puce,
tant qu'à faire.
C'est pas plus mal, si les specs sont sèches.
Tout ce que je peux dire:
- les heures sup', c'est crevant
Keynectis a surement été demandé, attendu, ..., par Thalès - chef
d'orchestre, mais il me semble bien que le ministère voulait quelqu'un
d'autre.
Presque ça. En fait, c'est le contraire ;)
Je ne sais pas si les specs ICAO autorisent un Etat à avoir plusieurs
clés racine, mais il est certain que l'Etat peut déleguer la fabrication
des passeports à plusieurs fournisseurs, y compris plusieurs
fournisseurs de PKI.
Tant que le fournisseur de PKI sait générer un PKCS#10 pour
se faire authentifier par la racine, et sait faire des
signatures telles que définies par l'ICAO, alors tout va bien.
On aurait pu imaginer que l'Etat ne génère que sa clé racine, et que
différents fournisseurs puissent la mettre en oeuvre dans des matériels
différents, mais en pratique c'est très difficile à faire proprement. La
faute aux fournisseurs de HSM.
On sort du cadre de ce newsgroup, puisque le dit blocage ne concerne
pas l'IGC, mais puisqu'on en cause...
Pour en revenir au fil initial, j'ai rapidement parcouru le site
www.icao.int, j'ai trouvé quelques docs plus ou moins techniques, mais
je retombe souvent sur leur CDROM-à-acheter-qui-contient-tout. Difficile
pour le citoyen curieux de se faire une idée de l'ensemble.
828*1024/8 interrupts à la secondes - bien tiens ... il reste quoi comme
temps CPU ?
Sylvain wrote:Philippe Martin wrote on 15/04/2006 21:39:Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à
~70000 bauds, je trouve ça balaise.
pour une communication à 414 ou 828 Kbds moi je trouve ça null.
Sylvain.
828*1024/8 interrupts à la secondes - bien tiens ... il reste quoi comme
temps CPU ?
Sylvain wrote:
Philippe Martin wrote on 15/04/2006 21:39:
Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à
~70000 bauds, je trouve ça balaise.
pour une communication à 414 ou 828 Kbds moi je trouve ça null.
Sylvain.
828*1024/8 interrupts à la secondes - bien tiens ... il reste quoi comme
temps CPU ?
Sylvain wrote:Philippe Martin wrote on 15/04/2006 21:39:Quel est le débit ?
Un chip à ~5MHz qui arrive as encrypter et transférer des données à
~70000 bauds, je trouve ça balaise.
pour une communication à 414 ou 828 Kbds moi je trouve ça null.
Sylvain.
On Fri, 14 Apr 2006, Erwan David wrote:Sauf que si on craque le logiciel on peut industrialiser les fausses
puces.
Et tu imites comment la signature RSA2048?
On Fri, 14 Apr 2006, Erwan David wrote:
Sauf que si on craque le logiciel on peut industrialiser les fausses
puces.
Et tu imites comment la signature RSA2048?
On Fri, 14 Apr 2006, Erwan David wrote:Sauf que si on craque le logiciel on peut industrialiser les fausses
puces.
Et tu imites comment la signature RSA2048?
Et tu imites comment la signature RSA2048?
Je ne connais pas le système employé: statique ou dynamique ?
Statique: la signature RSA2048 dont Erwann ABALEA parle est une valeur
mise dans la puce en fabrication, signant les données (indentité,
photo..)
Dynamique: cette valeur est au contraire calculée par la puce à
chaque fois qu'elle est lue et authentifiée par un lecteur, en
fonction notamment d'une épreuve émise par le lecteur; la puce
contient une clé privée, dont la clé publique est certifiée par
l'émetteur.
Si c'est statique, je ne vois pas ce qui empêche des fausses puces
contenant des copies serviles de vraies, et ce de manière finalement
plus simple/efficace que pour du papier: le fait que le passeport
contrefait soit électronique rend moins probable que son support soit
examiné de près
[...]. En effet j'ai cru comprendre que
la protection contre la lecture non autorisée est faible
et même: je vois mal comment se protéger contre le piégeage
d'un vrai lecteur utilisé par un vrai douanier, et collectant
systématiquement les données pour le compte du faussaire.
Si c'est dynamique, pour faire un faux, il faudrait par exemple
introduire un trojan dans le système de personnalisation, qui
parvienne à copier les clés privées injectées dans les vraies
puces
ou à faire produire uen signature de plus;
ou monter une attaque "side channel" contre une vraie puce.
Pas absolument impossible, mais en tout cas un nettement
plus gros obstacle pour le faussaire.
Et tu imites comment la signature RSA2048?
Je ne connais pas le système employé: statique ou dynamique ?
Statique: la signature RSA2048 dont Erwann ABALEA parle est une valeur
mise dans la puce en fabrication, signant les données (indentité,
photo..)
Dynamique: cette valeur est au contraire calculée par la puce à
chaque fois qu'elle est lue et authentifiée par un lecteur, en
fonction notamment d'une épreuve émise par le lecteur; la puce
contient une clé privée, dont la clé publique est certifiée par
l'émetteur.
Si c'est statique, je ne vois pas ce qui empêche des fausses puces
contenant des copies serviles de vraies, et ce de manière finalement
plus simple/efficace que pour du papier: le fait que le passeport
contrefait soit électronique rend moins probable que son support soit
examiné de près
[...]. En effet j'ai cru comprendre que
la protection contre la lecture non autorisée est faible
et même: je vois mal comment se protéger contre le piégeage
d'un vrai lecteur utilisé par un vrai douanier, et collectant
systématiquement les données pour le compte du faussaire.
Si c'est dynamique, pour faire un faux, il faudrait par exemple
introduire un trojan dans le système de personnalisation, qui
parvienne à copier les clés privées injectées dans les vraies
puces
ou à faire produire uen signature de plus;
ou monter une attaque "side channel" contre une vraie puce.
Pas absolument impossible, mais en tout cas un nettement
plus gros obstacle pour le faussaire.
Et tu imites comment la signature RSA2048?
Je ne connais pas le système employé: statique ou dynamique ?
Statique: la signature RSA2048 dont Erwann ABALEA parle est une valeur
mise dans la puce en fabrication, signant les données (indentité,
photo..)
Dynamique: cette valeur est au contraire calculée par la puce à
chaque fois qu'elle est lue et authentifiée par un lecteur, en
fonction notamment d'une épreuve émise par le lecteur; la puce
contient une clé privée, dont la clé publique est certifiée par
l'émetteur.
Si c'est statique, je ne vois pas ce qui empêche des fausses puces
contenant des copies serviles de vraies, et ce de manière finalement
plus simple/efficace que pour du papier: le fait que le passeport
contrefait soit électronique rend moins probable que son support soit
examiné de près
[...]. En effet j'ai cru comprendre que
la protection contre la lecture non autorisée est faible
et même: je vois mal comment se protéger contre le piégeage
d'un vrai lecteur utilisé par un vrai douanier, et collectant
systématiquement les données pour le compte du faussaire.
Si c'est dynamique, pour faire un faux, il faudrait par exemple
introduire un trojan dans le système de personnalisation, qui
parvienne à copier les clés privées injectées dans les vraies
puces
ou à faire produire uen signature de plus;
ou monter une attaque "side channel" contre une vraie puce.
Pas absolument impossible, mais en tout cas un nettement
plus gros obstacle pour le faussaire.
Il semble que la puce du nouveau passeport ne contienne que la photo
numérisée du titulaire. Ce n'est pas très "biométrique" ...
Cela n'empèche pas deux personnes se ressemblant plus ou moins de
partager le même passeport, d'autant plus que le passeport est
valable 10 ans et qu'en 10 ans on change.
Il devait y avoir les empreintes digitales numérisées qui elles
pouvaient identifier le porteur du passeport sans aucun doute.
Pourquoi ça été abandonné ?
Il semble que la puce du nouveau passeport ne contienne que la photo
numérisée du titulaire. Ce n'est pas très "biométrique" ...
Cela n'empèche pas deux personnes se ressemblant plus ou moins de
partager le même passeport, d'autant plus que le passeport est
valable 10 ans et qu'en 10 ans on change.
Il devait y avoir les empreintes digitales numérisées qui elles
pouvaient identifier le porteur du passeport sans aucun doute.
Pourquoi ça été abandonné ?
Il semble que la puce du nouveau passeport ne contienne que la photo
numérisée du titulaire. Ce n'est pas très "biométrique" ...
Cela n'empèche pas deux personnes se ressemblant plus ou moins de
partager le même passeport, d'autant plus que le passeport est
valable 10 ans et qu'en 10 ans on change.
Il devait y avoir les empreintes digitales numérisées qui elles
pouvaient identifier le porteur du passeport sans aucun doute.
Pourquoi ça été abandonné ?
