Ma banque m'envoie une nouvelle carte à puce, et le code secret est inchangé.
Cela signifie que la PassPhrase (code secret) n'est pas limité spatialement à la carte le temps de débloquer la clé secrète, mais qu'il est stocké ailleurs.
Je pensais que la sécurité physique du système postulait:
-jamais de backup d'une clé secrète, ni logiciel ni matériel.
-jamais de backup de la passphrase.
N'est-ce pas une porte ouverte à des attaques?
--
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
On est tout à fait d'accord que dans une application vérification de signature, rien n'est secret, donc rien à récupérer par DPA. Par contre pour du chiffrement, ce que l'on chiffre avec l'exposant public est par définition secret (puisque l'on prends la peine de le chiffrer), et il faut prendre un minimum de précautions.
à commencer par le produire en interne ou le recevoir chiffré et le déchiffrer/rewrapper - sinon ce qui vient de l'extérieur est par définition susceptible d'être corrumpu, non ?
Il y a un exemple relativement simple dans l'application cartes de tachygraphes, page 263 à 267 de
quand le machin est sorti (2004, 5?) j'ai choisi de ne pas l'implémenter, principalement pour des raisons marketing, depuis je ne suis son actualité de près.
Mon modèle de license est un "one-time-fee". A partir d'une quantité genre 100k, c'est nettement moins cher que le surcout d'un cryptoprocesseur et des options éventuellement inutiles qui viennent avec (pléthore relative de RAM et EEPROM);
pour une carte mono-service-""basique"" (type transport) sûrement, ailleurs je considère que le gâchis viendrait du fait de ne pas utiliser les services cartes plutôt que de la mémoire persistante disponible.
malgré cela, je ne vends pas ma librairie tous les jours (euphémisme) pour mettre dans une carte à puce.
la R&D crypto des fabriquants d'OS cartes est généralement une zone très fermée (pour le moins), il ne m'étonne pas que la sous-traitance est sûrement jamais pratiquée, heureusement penserais-je même.
Sylvain.
Francois Grieu wrote on 09/04/2007 13:17:
euh une attaque DPA sur un exposant public ??...
On est tout à fait d'accord que dans une application vérification de
signature, rien n'est secret, donc rien à récupérer par DPA. Par contre
pour du chiffrement, ce que l'on chiffre avec l'exposant public est
par définition secret (puisque l'on prends la peine de le chiffrer),
et il faut prendre un minimum de précautions.
à commencer par le produire en interne ou le recevoir chiffré et le
déchiffrer/rewrapper - sinon ce qui vient de l'extérieur est par
définition susceptible d'être corrumpu, non ?
Il y a un exemple relativement simple dans l'application cartes de
tachygraphes, page 263 à 267 de
quand le machin est sorti (2004, 5?) j'ai choisi de ne pas
l'implémenter, principalement pour des raisons marketing, depuis je ne
suis son actualité de près.
Mon modèle de license est un "one-time-fee". A partir d'une quantité
genre 100k, c'est nettement moins cher que le surcout d'un
cryptoprocesseur et des options éventuellement inutiles qui
viennent avec (pléthore relative de RAM et EEPROM);
pour une carte mono-service-""basique"" (type transport) sûrement,
ailleurs je considère que le gâchis viendrait du fait de ne pas utiliser
les services cartes plutôt que de la mémoire persistante disponible.
malgré cela, je ne vends pas ma librairie tous les jours (euphémisme)
pour mettre dans une carte à puce.
la R&D crypto des fabriquants d'OS cartes est généralement une zone très
fermée (pour le moins), il ne m'étonne pas que la sous-traitance est
sûrement jamais pratiquée, heureusement penserais-je même.
On est tout à fait d'accord que dans une application vérification de signature, rien n'est secret, donc rien à récupérer par DPA. Par contre pour du chiffrement, ce que l'on chiffre avec l'exposant public est par définition secret (puisque l'on prends la peine de le chiffrer), et il faut prendre un minimum de précautions.
à commencer par le produire en interne ou le recevoir chiffré et le déchiffrer/rewrapper - sinon ce qui vient de l'extérieur est par définition susceptible d'être corrumpu, non ?
Il y a un exemple relativement simple dans l'application cartes de tachygraphes, page 263 à 267 de
quand le machin est sorti (2004, 5?) j'ai choisi de ne pas l'implémenter, principalement pour des raisons marketing, depuis je ne suis son actualité de près.
Mon modèle de license est un "one-time-fee". A partir d'une quantité genre 100k, c'est nettement moins cher que le surcout d'un cryptoprocesseur et des options éventuellement inutiles qui viennent avec (pléthore relative de RAM et EEPROM);
pour une carte mono-service-""basique"" (type transport) sûrement, ailleurs je considère que le gâchis viendrait du fait de ne pas utiliser les services cartes plutôt que de la mémoire persistante disponible.
malgré cela, je ne vends pas ma librairie tous les jours (euphémisme) pour mettre dans une carte à puce.
la R&D crypto des fabriquants d'OS cartes est généralement une zone très fermée (pour le moins), il ne m'étonne pas que la sous-traitance est sûrement jamais pratiquée, heureusement penserais-je même.
