Cher journal,
Récemment, j'ai renouvelé ma carte d'identité. Comme j'avais lu la très bonne dépêche sur les cartes OpenPGP et une puce qui tenait à ma carte d'identité, je me suis dit que c'était l'occasion de tester les certificats x509 inclus dedans. Au final, c'est une smartcard comme les autres1. Il faut dire que l'état fournit un middleware opensource qui est directement compatible avec le standard PKCS11. J'ai donc téléchargé les logiciels adéquats. Ainsi que opensc.
Ensuite, on peut s'amuser à voir que ça marche avec pkcs11-tool --module /usr/lib/x86_64-linux-gnu/libbeidpkcs11.so.0 --login --test. Malheureusement, pour moi, sous Debian, on dirait qu'il y a un problème de dépendance sur les binaires fournis pour Debian et ça ne marche pas, par contre, en recompilant (et installant) les sources, c'est bon. On peut aussi voir les données avec pkcs15-tool -D. On voit donc qu'il y a des certificats lisibles. Pourquoi donc ne pas les utiliser pour s'authentifier sur le PC2 avec pam-pkcs11.
Je dois dire qu'au final, c'est relativement simple, une fois qu'on a compris quels fichiers devaient être modifié. Je me suis grandement inspiré de deux posts qui parle des smartcard en général et pas d'une eID sur le forum Ubuntu pour cela. Premièrement, on créés les répertoires /etc/pam_pkcs11, /etc/pam_pkcs11/cacerts et /etc/pam_pkcs11/crls. Ensuite, on copie la configuration par défaut gzip -ckd /usr/share/doc/libpam-pkcs11/examples pam_pkcs11.conf.example.gz | sudo tee /etc/pam_pkcs11/pam_pkcs11.conf. Il faut modifier ce fichier pour qu'il utilise la bibliothèque donnée plus haut, la variable module devient:
module = /usr/lib/x86_64-linux-gnu/libbeidpkcs11.so.0Il faut aussi définir un mapper pour faire le lien entre votre compte et un des champs de la carte. Un défaut que je trouve à cette carte d'identité, c'est que le Common Name contient l'usage du certificat, c'est-à-dire que le certificat pour s'authentifier a pour CN: Xavier Claude (Authentication). Il faut donc un fichier pour associer ce compter à votre compte du système. On définit le fichier /etc/pam_pkcs11/cn_map qui contient:
Xavier Claude (Authentication) -> claudexEt dans /etc/pam_pkcs11/pam_pkcs11.conf, on change les lignes:
use_mappers = cn;et
mapper cn {
#debug = true;
module = internal;
mapfile = file:///etc/pam_pkcs11/cn_map
}Ensuite, il faut extraire le certificat utilisé pour signer les certificats utilisateurs qui sera utilisé pour valider le certificat que vous présentez, pour cela, un coup de pkcs15-tool --read-certificate 4 (4 étant l'id donné par la commande pkcs15-tool -D, il est aussi possible de l'extraire via l'interface graphique eid-viewer qui présente la hiérarchie de signature de manière claire). Il faut placer ce fichier dans /etc/pam_pkcs11/cacerts. Ensuite, on met à jour les liens:
cd /etc/pam_pkcs11/cacerts
sudo pkcs11_make_hash_linkComme l'article que j'ai lié, j'ai d'abord testé avec sudo, parce que c'est très facile. On ajoute dans /etc/pam.d/sudo, la ligne:
auth sufficient pam_pkcs11.soEt on peut directement tester avec un sudo -i et ça devrait marcher si vous n'avez pas retirer la carte du lecteur depuis le début. Et oui, il y a un autre problème malgré la recompilation, on a le message suivant quand on essaye à froid:
(process:25550): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper program instead.
For further details, see:http://www.gtk.org/setuid.html
Refusing to initialize GTK+.
Quand on a déjà rentré le PIN avec, par exemple, un pkcs11-tool --module /usr/lib/x86_64-linux-gnu/libbeidpkcs11.so.0 --login --test, la carte est déjà délocké et ne redemande pas le PIN.
Après, on peut s'amuser à aller plus loin avec pkcs11_eventmgr, qui peut locker le compte quand on retire la carte du lecteur. Le fichier de config est le suivant (vous remarquerez qu'il n'y a rien pour délocker le compte, c'est un exercice laissé au lecteur3). Voici un exemple de fichier de conf pour KDE 4.14 (ça fait varier le screen locker) à placer dans/etc/pam_pkcs11/pkcs11_eventmgr.conf:
pkcs11_eventmgr {
# Run in background? Implies debug=false if true
#daemon = true;
# show debug messages?
#debug = false;
debug = true;
# polling time in seconds
polling_time = 1;
# expire time in seconds
# default = 0 ( no expire )
expire_time = 0;
# pkcs11 module to use
pkcs11_module = /usr/lib/x86_64-linux-gnu/libbeidpkcs11.so.0;
#
# list of events and actions
# Card inserted
event card_insert {
# what to do if an action fail?
# ignore : continue to next action
# return : end action sequence
# quit : end program
on_error = ignore ;
# You can enter several, comma-separated action entries
# they will be executed in turn
#action = "play /usr/share/sounds/warning.wav",
# "xscreensaver-command -deactivate";
#action = "qdbus | grep kscreenlocker_greet | xargs -I {} qdbus {} /MainApplication quit";
}
# Card has been removed
event card_remove {
on_error = ignore;
#action = "play /usr/share/sounds/error.wav",
# "xscreensaver-command -lock";
action = "qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock";
}
# Too much time card removed
event expire_time {
on_error = ignore;
action = "/bin/false";
}
}Après, on peut le lancer avec pkcs11_eventmgr, retirer la carte du lecteur et voir l'écran se verrouiller.
En conclusion, à cause des problèmes avec la présentation de la fenêtre GTK (le mauvais paquet Debian ainsi que l'exécution en suid) pour afficher le code PIN, cela reste un gadget pour l'instant. Les prochaines étape sont le délockage de l'écran de veille, l'identification SSH et si je suis motivé, un rapport de bug.
-
ça veut donc dire qu'il y a quelques adaptations à faire. ↩
-
la question est rhétorique. Sinon, le journal a peu d'intérêt. ↩
-
bon, je n'ai rien troué pour délocker le compte de manière sûre. Parce que ce que j'ai trouvé, en commentaire du fichier de conf, ça délocke le compte quelque soit la carte qu'on rentre dedans. Et comme on est dimanche soir, j'ai la flemme de chercher plus loin. ↩
# Noël
Posté par octane . Évalué à 10.
rhaaaaaaah! Mais c'est Noël? Mais c'est énorme! C'est génial, il faudrait en faire un nourjal rien que pour ça? \o/ L'état qui file des sources, standard, mais juste rhaaaah lovely quoi. Et il y a même de la doc pour les gens sous nux, c'est le genre de truc qui fait plaisir pour commencer 2015 :)
[^] # Re: Noël
Posté par claudex . Évalué à 10. Dernière modification le 04 janvier 2015 à 23:08.
Ça fait des années que c'est comme ça, je pense que c'est depuis l'introduction de la carte d'identité électronique.
Edit: les commentaires de l'époque ont l'air d'accord avec moi https://linuxfr.org/users/yoda222/journaux/e-id-pgp#comment-615798
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Question bête
Posté par rakoo (site web personnel) . Évalué à 7.
Une identité "électronique" fournie par l’État a l'air bien intéressante (surtout que de plus en plus de démarches peuvent être faites directement sur l'ordinateur), mais ici l’implémentation m'a l'air douteuse: si j'ai bien compris, l’État te fournit un certificat qu'il a généré lui-même ? Donc tous ceux qui sont sur la chaine entre toi et lui ont potentiellement eu accès a ta clé privée ?
[^] # Re: Question bête
Posté par j_m . Évalué à 3.
Quoi on peut sortir la clé privée de la carte ? Je crois pas, sinon ça n'a pas beaucoup de sens, dès que tu donnes ta carte pour signer un truc on peut te prendre ta clé privée en même temps…
[^] # Re: Question bête
Posté par rakoo (site web personnel) . Évalué à 7.
Non, je parle du fait que la clé n'a pas été générée par le citoyen, et donc il doit faire confiance a tous ceux qui sont entre celui qui a généré la clé et lui-même (j'imagine qu'il doit y avoir l’État avec un ou deux contractants dans le coup), donc la on est avant même que la carte arrive chez la personne.
[^] # Re: Question bête
Posté par barmic . Évalué à 4.
Je ne sais pas comment ça se passe chez nos voisins belges, mais en France je sais que certains organismes de l'état s'appuient sur certinomis qui est une entreprise de La Poste. Je ne sais pas si ont peut avoir le même niveau de confiance qu'en La Poste. Je ne sais pas non plus s'ils acceptent les csr.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Question bête
Posté par claudex . Évalué à 3.
Vu qu'on ne peut pas lire la clef privée, il ne faut avoir confiance qu'entre le moment où la clef privée est générée et le moment où la clef est stockée sur la puce. Ce qui réduit pas mal le nombre de faille possible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Question bête
Posté par rakoo (site web personnel) . Évalué à 5.
Mouais. Pour moi, c'est plus ou moins équivalent aux trucs comme Protonmail, qui jurent-promis-juré-craché que le mail est chiffré dès qu'il arrive sur leur serveur et qu'ils jettent la version en clair sans la conserver. C'est-à-dire que j'ai pas du tout confiance en leur machin, en fait.
[^] # Re: Question bête
Posté par claudex . Évalué à 9.
Si tu as peur que les gens qui manipulent les cartes d'identité avec ta clef, tu devrais avoir encore plus peur de l'usurpation d'identité qu'ils peuvent faire en fabricant une fausse carte d'identité à ton nom.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Question bête
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 05 janvier 2015 à 22:56.
ce n'est pas ta clef si quelqu'un te l'a fournie
l'état a tout pouvoir ?
c'est justement la question : savoir gérer son identité de manière autonome (et ce n'est pas si facile avec l'administration), en tenant compte de la sécurité et des processus à suivre cela se complique encore…
[^] # Re: Question bête
Posté par aiolos . Évalué à 7.
Non, là on parle de la responsabilité régalienne de l'état de gérer l'identité civile. Dans ce contexte, c'est son rôle de certifier ton identité. S'il peut certifier ce qu'il veut, qu'il ait ou non généré ta clef ne change pas grand chose puisqu'il peut faire passer n'importe quelle clef pour légitime.
Avoir une autre identité que tu gère toi même, c'est pas incompatible (sur une autre carte).
[^] # Re: Question bête
Posté par BAud (site web personnel) . Évalué à 2.
Nous sommes donc en fait d'accord. Gérer sa propre identité n'étant pas forcément à déléguer à l'état ni à son administration, point que je relevais, remettant pour certains en cause cette responsabilité régalienne et la remettant entre les mains de chacun de s'affirmer responsable et savoir gérer son identité de bout en bout (plus facile à dire qu'à faire).
[^] # Re: Question bête
Posté par flan (site web personnel) . Évalué à 4.
Euh, non. Il n'y a qu'en celui qui a généré la clef et l'a mise sur la carte-à-puce qu'il doit faire confiance (et qui de toute façon, peut tout signer, donc on s'en moque un peu qu'il ait accès à la clef privée). Le nombre d'intermédiaires qui ont accès à la carte n'a aucune importance.
C'est un peu le principe d'une carte-à-puce : une fois que la clef privée est injectée dedans, tu ne peux pas l'en retirer (si la carte-à-puce est de bonne qualité).
Et heureusement que la clef privée n'est pas générée par le citoyen directement, ça serait le meilleur moyen d'avoir de mauvaises clefs (presque personne ne sait correctement générer une clef et faire en sorte qu'il n'en reste aucune trace). Si c'est pour avoir une clef de 512 bits qui est en plus stockée sur une clef USB abandonnée, ce n'est pas la peine de se casser la tête :D
[^] # Re: Question bête
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
la clé a été générée {par, sur} la carte; elle n'a jamais existé ailleurs.
le contractant en question lance la génération de ta clé sur la carte et n'y a jamais accès (même si il le voulait)
l'État contrôle le CA: il peut de toute façon révoquer ta carte, en créer une autre avec un autre certificat, le signer et faire toute les conneries imaginables "avec ton identité". ce qui était déjà possible avec les identités papiers, donc rien de neuf
[^] # Re: Question bête
Posté par rakoo (site web personnel) . Évalué à 3.
Je dois avouer que je n'y connais absolument rien, merci pour les détails.
Sauf que l'identité papier ne permet pas de signer, elle permet juste d'identifier. Ici on parle d'une clé qui permet d'identifier mais aussi d'authentifier des messages, transactions ou autre. Ça a un pouvoir vachement plus grand, pour moi ça présente un plus grand danger et ça mérite beaucoup plus de faire gaffe à où la clé a trainé.
[^] # Re: Question bête
Posté par claudex . Évalué à 3.
Elle contient quand même une copie de la signature qui permet de montrer que tu signe bien avec ta propre signature.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Question bête
Posté par jcs (site web personnel) . Évalué à 3.
Pour bien comprendre ce qui se passe et donc pouvoir décider si on a confiance ou pas, il peut être utile (et même indispensable à mon avis) de lire la politique de certification de cette Autorité de certification. En fait plus précisément c'est la "Déclaration des pratiques de certification" qui nous intéresse.
Pour ceux qui voudrait tout lire, la version en français est ici : http://repository.eid.belgium.be/downloads/citizen/fr/CPS_CitizenCA.pdf
Et justement dans la partie 4.4 (Acceptation du certificat) il est précisé :
Donc il semble les clés ne sont générées que sous le contrôle du citoyen. Mais je me demande comment ça se passe exactement en pratique.
[^] # Re: Question bête
Posté par dj_ (site web personnel) . Évalué à 4.
On doit aller chercher la carte avec sa convocation (qui comporte les codes puk et pin), l'employé de la commune introduit la carte dans son pc pour l'activer (grâce au code puk)
[^] # Re: Question bête
Posté par claudex . Évalué à 7.
Non, ça veut dire que les certificats ne sont utilisables qu'après l'activation et cette activation se fait en présence du citoyen, mais les clef ont été gérée bien plus tôt (environ 15 jours avant que je reçoive ma convocation me signalant que la carte était arrivée à la commune).
Le code PUK de la carte fait 12 chiffres, tu en reçois 6, le registre national contient les 6 autres. Tu te rend à la commune avec ton papier et le code PUK complet est utilisé pour activer la carte (au passage, la procédure les active au niveau de l'état).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Question bête
Posté par jcs (site web personnel) . Évalué à 1.
Merci pour la précision. En effet, en lisant la DPC un peu plus en détails, il est (plus ou moins) clair que les clés et les certificats sont générés et injectés avant l'activation initiale de la carte. Par contre il n'y a pas grand chose sur les conditions de générations des clés et les demandes de certificats (personnel de confiance, dual control, sécurisation des locaux…). Mais il y a peut-être d'autres documents disponibles.
[^] # Re: Question bête
Posté par Krunch (site web personnel) . Évalué à 4.
Théoriquement, non. En pratique, ça doit être faisable mais ça requiert un accès physique à la carte, un minimum d'expertise en attaque par canal auxiliaire et du matériel adéquat.
http://en.wikipedia.org/wiki/Side_channel_attack
J'ai pas vu de publication à ce sujet spécifiquement pour la carte d'identité belge. Je suspecte que ça signifie qu'il n'y a pas assez de gens intéressés plutôt que la carte soit super séquioure.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Question bête
Posté par aiolos . Évalué à 3.
C'est marrant, moi j'aurais formulé exactement dans l'autre sens :
Théoriquement, oui, par des attaques physiques ou par canaux auxiliaires. En pratique, ça requiert un accès physique à la carte,
un minimumpas mal d'expertise en attaque par canal auxiliaire et du matériel adéquat.[^] # Re: Question bête
Posté par Krunch (site web personnel) . Évalué à 3.
J'avoue que j'ai hésité :)
Mais considérer que la clef est impossible à extraire me semble plus théorique que pratique.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Question bête
Posté par aiolos . Évalué à 1.
:-) Effectivement !
[^] # Re: Question bête
Posté par dj_ (site web personnel) . Évalué à 3.
oui c'est génial, avec un simple lecteur de carte et un ordinateur on peut faire sa déclaration d’impôts (et accéder aux documents), postuler pour travailler dans la fonction publique, demander sa retraite (et voir toutes les info en rapport comme la carrière), demander des documents a sa commune, s'occuper de sa mutuelle santé, utiliser la signature pour valider une connexion VPN
Les gens peuvent signer un document (même un émail) pour leur donner une valeur légale. Et les ministres signent des lois avec, ça risque de devenir pareil pour le roi dans quelques temps
Le seul truc que j'ai trouvé bizarre (avec mes trèèèsssss faibles connaissances en sécurité, je suis pas informaticien), c'est que le code PIN qu'on reçoit en cas de renouvellement de carte est le même que celui qu'on avait sur l'ancienne carte.
C'est une obligation technique pour que l'état génère la clé? (oui question très conne désolé, mais quand on reçoit une nouvelle carte de banque y a un nouveau code pin car la banque ne connaît pas notre code)
[^] # Re: Question bête
Posté par Krunch (site web personnel) . Évalué à 5.
Ça dépend des banques. Certaines donnent le même PIN lors du renouvellements de la carte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Question bête
Posté par rakoo (site web personnel) . Évalué à 2.
Faux, j'ai moi-même renouvelé ma carte bancaire récemment et le code PIN est le même. D'ailleurs je ne me souviens pas avoir choisi le code PIN a un quelconque moment.
Du coup si c'est le cas avec cette e-carte d'identité, ça ne fait que confirmer mes craintes.
[^] # Re: Question bête
Posté par dj_ (site web personnel) . Évalué à 2.
On va dire que ça limite la confiance qu'on peut avoir avec la clé, pour ne pas l'utiliser pour des documents dont on ne veut pas que l'état aie accès
Comme dit krunch pour les banques, ça doit dépendre.
[^] # Re: Question bête
Posté par Yann Hodique (site web personnel) . Évalué à 5.
Ça n'a pas grand chose à voir, le fait que quelqu'un connaisse le PIN ne va faire une différence que dans le cas où il se trouve en possession de la carte elle-même, puisque c'est ce qui "débloque" la clef privée pour utilisation pendant la session.
de chances de succès, avec N le nombre d'essais disponibles avant blocage permanent et M le nombre de chiffres dans le PIN), autant la recherche de carte en ayant le PIN a assez peu de chances d'aboutir, sauf à recourir à la coercition physique ;)
En gros, PIN + carte = clef privée, mais PIN seul ou carte seule ne servent à rien.
Et autant la recherche de PIN en ayant la carte n'est pas totalement absurde: (
Pour utilisation (en chiffrement j'imagine) sur des documents que l'ont veut garantir secrets pour l'état, la vraie question est de savoir si l'état a la clef privée. Il y a globalement 3 cas de figure:
- la clef est générée hors-carte, injectée dans la carte, signée, et sauvegardée par l'état (cas d'utilisation: l'état se réserve explicitement le droit d'usurper l'identité de la personne)
- la clef est générée hors-carte, injectée dans la carte, signée, et détruite (cas d'utilisation: l'état n'entend pas usurper l'identité, mais se fait confiance à lui-même pour que ça n'arrive pas)
- la clef est générée directement dans la carte, et signée (cas d'utilisation: l'état veut garantir l'impossibilité, y compris pour lui-même, d'usurper l'identité)
Si le processus utilise le 1er cas, effectivement aucune confiance à avoir. Si c'est le 2ème cas, la confiance équivaut à la confiance placée dans le mécanisme de destruction (et en particulier à celle placée dans l'impossibilité d'intercepter la clef avec destruction). Si c'est le 3ème cas, la confiance équivaut à celle qu'on a dans le fait que la carte ne peut jamais recracher la clef privée (autrement dit qu'elle n'est pas trouée, puisque ça fait partie des specs), et que la clef est de suffisamment bonne qualité pour ne pas se suicider (à savoir leaker des informations sur elle-même lors d'opérations légitimes). Au passage, évidemment la qualité d'une clef décroît avec le temps, à mesure que les attaques contre les algos qui l'ont générée se perfectionnent et/ou bénéficient de plus de puissance pour tourner.
Personnellement je n'utiliserais pas une clef générée hors-carte pour des secrets au niveau "gouvernemental"
Évidemment dans tous les cas, si on ne fait pas confiance en l'état pour respecter la procédure qu'il prétend utiliser (ou s'il ne prétend rien du tout), on est par défaut dans le 1er cas :)
Mais encore une fois c'est globalement indépendant du fait que le PIN soit ou non sauvegardé quelque part.
[^] # Re: Question bête
Posté par flan (site web personnel) . Évalué à 3.
Depuis quand signe-t-on une clef privée ?
Une clef privée sert à signer la demande de certificat puis le certificat lui-même (enfin, ce n'est pas la même clef privée utilisée, évidemment), mais jamais la clef elle-même n'est signée.
[^] # Re: Question bête
Posté par Yann Hodique (site web personnel) . Évalué à 2.
oui tout à fait, j'ai fait un raccourci plus qu'approximatif et bien malheureux. D'autant plus bête que tout ce qui se rapporte à la signature du certificat est complètement hors-sujet dans ce que je raconte :)
[^] # Re: Question bête
Posté par Bernez . Évalué à 3.
Il me semble que non. Le code PIN permet d'avoir le droit de faire effectuer, par la carte, des calculs cryptographiques qui utilisent la clé privée. La clé privée en elle-même ne sort jamais de la carte.
Ça fait quand même une différence importante : en cas de vol du code PIN (à l'occasion d'une utilisation de la carte sur un ordinateur non fiable ou troué, par exemple), il suffit de changer son code PIN pour que la clé privée reste protégée même en cas de vol de la carte.
[^] # Re: Question bête
Posté par Yann Hodique (site web personnel) . Évalué à 1.
c'est précisément ce que je dis explicitement un peu plus loin.
Mon équation se lit au sens strict: le couple (PIN, carte) est essentiellement la clef privée (pour toutes les opérations légales). Tu sembles lire ça comme "le couple (PIN, carte) donne la clef privée", ce qui serait effectivement faux. Et oui, pour les cartes où le changement de PIN est possible (ce qui n'est pas toujours vrai), la relation d'équivalence est temporelle: les anciens PINs ne servent à rien
[^] # Re: Question bête
Posté par j_m . Évalué à 1.
Strictement parlant, ta parenthèse n'était pas présente, et c'est justement la parenthèse que tu ajoutes qui rend vrai cette égalité. Alors oui, c'était implicite, c'était quelque part dans le contexte mais la lecture en est tellement ralentie.
Il eût mieux fallu ajouter un ou deux mots de français pour rendre plus lisible ton équation.
[^] # Re: Question bête
Posté par 2PetitsVerres . Évalué à 2.
J'ai l'impression que ça dépend. Sur ma carte française, j'ai un code qui a été choisi par la banque et au renouvèlement j'ai eu le même, sur ma carte belge j'ai un code que je peux changer mais il me semble que lors du renouvèlement j'ai eu le même (mais je ne suis pas sur, c'était il y a longtemps) et sur ma carte luxelbourgeoise, au renouvèlement elle est venue avec un code différent de l'ancien.
Pour ma carte d'identité elle avait un code par défaut (aléatoire je suppose) mais on pouvait le changer. (à l'époque où j'avais une eID, je suis revenu à une version "classique" maintenant…)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Standard
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Il n'existe pas de standard de carte à puce X.509 ? Parce que bon, la norme PKCS#11 « Cryptoki », qui ne définit qu'une API, et qui nécessite que chaque implémentation physique soit livrée avec une bibliothèque pour chaque plate-forme prise en charge, comment dire, c'est un peu de la merde, quand même…
[^] # Re: Standard
Posté par aiolos . Évalué à 6.
Réponse(s) courte(s) :
non, pas à ma connaissance.
oui
Réponse longue:
Comment dire ? Le milieu de la carte à puce est bouré d'implémentations propriétaires, de NDA et autre tracasseries… Ne serait-ce que pour acheter une cartes à quelques exemplaires afin de les évaluer, il faut souvent remplir des tonnes de paperasses…
Ensuite, pour les cartes et la crypto, tu va trouver plusieurs standards, plus ou moins contraignants :
- PKCS #11 pour les API en C d'accès à un tocken crypto
- PKCS #15 pour le système de fichier
- PKCS #1 / RFC 3447 pour les méthodes de chiffrement et signature RSA
- PIV pour les cartes standards des services américains, avec plusieurs versions selon les usages
- etc.
Mais, concernant X.509 par exemple, il n'y a pas (à ma connaissance, si vous connaissez, je suis preneur) de specifications générique pour le stockage des clefs et des chaines de certificats dans PKCS#15/l'applet de crypto. Tu va parfois les trouver dans les specs d'une application et/ou middleware (par exemple, openSC stocke le certificat et la clef aux mêmes "slots" respectivement dans une applet et dans PKCS#15)
[^] # Re: Standard
Posté par BAud (site web personnel) . Évalué à 4.
ah, bah, tu vas être bon pour initier une dépêche en espace de rédaction pour détailler la suite de la dépêche sur la carte OpenPGP évoquée dans ce journal : il est possible de faire une serial-dépêche (chacune évoquant un sujet et le détaillant).
[^] # Re: Standard
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Oui PKCS#11 ne définit qu'une API, et c'est tant mieux vu la diversité de matériels que tu peux trouver derrière (carte via lecteur USB, série, HSM accédé en réseau…). Ça a le mérite de définir un langage commun, c'est le principe même d'un pilote de matériel.
# Voyages…
Posté par lolop (site web personnel) . Évalué à 7.
Une question, si tu vas aux USA, sont-il en droit de te demander le PIN de ta carte comme ils peuvent te demander de déverrouiller ton disque dur chiffré?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Voyages…
Posté par Krunch (site web personnel) . Évalué à 2.
Ça semble probable.
Je vois deux contre mesure possibles :
* ne pas prendre ta carte quand on va aux ÉUA ;
* renoncer aux certificats quand tu obtiens ta carte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Voyages…
Posté par navaati . Évalué à 4.
Heu, on se calme, donner le code PIN ne permet pas aux douanes d'extraire la clef privée, donc après y être passé tu récupère ta carte, change le code PIN et tu as la garantie que la douane n'a pu signer/déchiffrer des trucs que dans le laps de temps pendant lequel ils ont eu la main physiquement sur la carte.
[^] # Re: Voyages…
Posté par Krunch (site web personnel) . Évalué à 2.
Ce qui n'empêche pas de prendre des précautions de base.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.