Bonjour à tous et merci à Sylvain pour sa réponse,
si j'ai bien lu "Ecole Centrale d'Electronique" et non d'informatique, je vous encouragerais plus à une analyse des possibilités crytpographiques du bout d'électronique que constitue une carte à puce plus qu'à ""perdre votre temps"" dans le carcan intellectuel du winlogon à la mode microsoft.
Ah mais tout comme l'Ecole Polytechnique Feminine (EPF) ne l'est plus depuis 1996, l'ECE ne fait pas que de l'électronique ! (tant qu'on est dans la pub, venez voir le site web tout nouvo tout bo www.ece.fr, ou si vous y tenez vraiment au salon de l'education à Paris, Pte de Versailles du 24 au 27 novembre, stand I20-I22, où je (Mathieu) serai présent samedi après midi).
Et pour le moment on n'est qu'en Ing1 (sur Ing5), et comme l'ECE est une école habilitée CTI (donc qui se doit de respecter des programmes pas trop éloignés de la CPGE en prépa intégrée) on est loin d'avoir choisi notre spécialisation... Notre PSTE étant classé en catégorie "informatique", il doit quand même tourner un minimum autour de ça (mais il est possible que le simple fait de programmer la carte puisse suffire, mais il faut que ça tienne la route niveau électronique derrière)
je veux dire par là que l'aspect utilisation d'une carte à puce par un soft est délimité (contraint) par ce soft lui-même et la carte n'est arbritrairement choisi que pour sa sécurité de stockage (qu'elle réalise très bien), toutefois le soft fonctionnerait à l'identique si la clé était en soft pur ou sur un bout de papier. de plus l'utilisation effective de la crypto carte est souvent réduite à la partie congrue, pour prendre l'exemple de Johann d'une signature et chiffrement de mail, la carte n'est utilisée (par 100% des CSP cartes du marché) que pour produire la signature digitale du message, c'est à dire que 1) la génération d'un aléa utilisé comme clé de chiffrement du mail est réalisé par le PC (qui ne sait pas ce que random signifie), 2) le chiffrement du mail via cette clé est également dévoulu au PC (après tout le message clair y est bien présent), le wrapping de la clé de chiffrement par la clé publique du destinataire itou (ce n'est que de la crypto clé publique ...), 3) coté destinataire, la carte ne sera utilisée que recouvrer la clé de chiffrement.
bref, dans de tels exemples 90% de la crypto est faite par soft et non par carte.
dès lors, si votre étude porte sur les possibilités d'un code embarqué (et non l'esthétisme de telle ou telle API) je vous conseillerais plus une étude comparative des possibilités / performances d'une carte comparée à un ""proc. normal"" (CPU d'ordinateur ou FGPA), en montrant qu'une utilisation pertinente de la carte (bonne répartition entre le PC et la carte) permet de supporter des algorithmes exigants en calcul, vous pourrez ébaucher des mécanismes originaux de protection d'information (réflexion sur les exigences d'une signature non répudiable) ou de droits (DRM ou aucun élément pleinement duplicable ne sera présent ou execution d'un processus par un milieu hostile (le PC) controlé par un code embarqué).
Le sujet du PSTE c'est "la cryptographie dans l'électronique embarquée", bon je reconnais maintenant que le sujet ne veut pas dire grand chose mais à l'époque on savait pas encore ;-) De toute façon on a encore une problématique à définir précisément, on va donc voir ce qu'on va étudier et surtout ce qu'on va réaliser (même si la partie réalisation c'est pas forcément le plus important du point de vue notation, c'est quand même ce sur quoi on voudrait passer le plus de temps !)
si la programmation du micro-controleur de la carte n'est pas le premier objectif de l'étude, l'utilisation d'une JavaCard facilitera grandement sa prise en main et son utilisation.
C'est compatible Infinity USB ? (parce que maintenant qu'on a investi...) Apparament non (et dans ce cas comment on fait alors ?)
chacun ayant fait sa pub, j'ai envie d'ajouter que je peux vous donner une dizaine de cartes ... si vous ne grattez pas son logo ,-)
Yes on prend !
Sylvain.
Mathieu, Antonin, Gilbert et Nicolas
