Et maintenant, quand j'ai presque ajouté la génération de
certificats auto-signés au poste de travail cryptographique basé sur les jetons cryptoarmpkcs PKCS # 11 et que j'étais prêt à commencer à écrire l'article, j'ai reçu une lettre comme celle-ci:
Nous sommes l'UZNIREK CA, nous avons eu des difficultés à émettre des ES au format pkcs # 11 pour EGAIS, le portail ne comprend pas les ES au format CSP Znamerek, nous vous demandons d'aider dans ce problème.
Je ne connaissais pas toutes les subtilités de travailler avec EGAIS, mais comme c'était PKCS # 11, j'ai suggéré d'utiliser l'utilitaire cryptoarmpkcs pour
générer une demande et installer un certificat pour un jeton après sa réception par l'autorité de certification. La réponse que j'ai reçue était quelque peu distrayante:
Hélas, le fait est que nous avons enregistré ES sur RuToken 2.0 via CryptoPro CSP, mais avec tous les paramètres appropriés, le portail EGAIS n'a pas vu l'ES sur le support clé, le client nous a contacté en support et nous avons constaté que le problème n'était pas le certificat de clé est écrit dans ce format, voici le manuel dev.rutoken.ru/display/KB/RU1051
.
J'ai (et pas seulement moi) déjà écrit à plusieurs reprises que beaucoup utilisent des jetons cryptographiques avec le support de la cryptographie russe comme
lecteurs flash ordinaires . Et c'était juste le cas lorsque la clé et le certificat n'étaient pas arrivés au jeton en tant qu'objets PKCS # 11. C'est dommage qu'ils n'aient pas suivi les conseils et n'aient même pas essayé de créer une demande. Mais j'ai alors décidé de tout mettre de côté et de déterminer comment et sur quels certificats EGAIS Rosalkogolregulirovanie sont délivrés. Et nous ne considérerons que les jetons cryptographiques PKCS # 11. La plus grande déception est l'accès à EGAIS uniquement via Windows et le navigateur IE. D'autre part, la génération d'une demande de certificat et l'installation d'un certificat peuvent également être effectuées sous n'importe quel système d'exploitation, s'il dispose de pilotes / bibliothèques pour le jeton correspondant.
Au moins les jetons PKCS # 11 JaCarta, RutokenECP-2.0, le jeton logiciel LS11SW2016 et même le
jeton cloud sont pris en charge sur MS Windows, Linux et OS X. Et pas seulement sur ces systèmes d'exploitation.
En fait, nous devons rendre hommage aux développeurs d'EGAIS. Ils ont proposé une technologie intéressante qui permet d'accéder à des certificats personnels (certificat plus paire de clés) stockés sur des jetons cryptographiques avec prise en charge de la cryptographie russe et de protéger le canal sur les certificats RSA. Bien que s'ils disaient A, alors on pourrait dire B, c'est-à-dire protéger le canal sur les algorithmes GOST-ov. La seule chose triste est que tout cela est conçu uniquement pour MS Windows (ou je me trompe?), Ou plutôt pour Internet Explorer. Et les utilitaires de génération de demandes de certificats pour EGAIS sont liés à un jeton particulier.
Mais l'utilitaire cryptoarmpkcs est multi-plateforme. De plus, il est capable de fonctionner avec n'importe quel jeton cryptographique PKCS # 11 qui prend en charge la cryptographie russe.
Alors, quelle est la particularité de la demande de certificat pour EGAIS? La principale caractéristique est la présence obligatoire dans le nom distinctif du titulaire du certificat (sujet DN) d'un champ supplémentaire unstucturedName (UN) (oid - 1.2.840.113549.1.9.2). Si le propriétaire du certificat est un entrepreneur individuel, la ligne «KPP =» est écrite dans ce champ, et si le propriétaire est une personne morale, alors cette ligne est écrite dans ce champ:
PPC = reason_code_of_tax_account_account:
À cet égard, l'exigence sur la première page de l'onglet de demande de certificat a été ajoutée au bouton EGAIS:
Une autre caractéristique est que les titulaires de certificats pour EGAIS peuvent être titulaires de licence du système de déclaration FSRAP (oid - 1.2.643.3.6.78.4.4). Cela doit également être pris en compte lors de la création d'une demande:
Une fois que tous les champs de la demande de certificat sont remplis et que vous avez confirmé l'exactitude des données, une paire de clés sera générée et la demande sera créée:
Si vous regardez la demande, vous pouvez y voir les oid-s (Extetnded Key Usage), qui sont nécessaires pour EGAIS Rosalkogolregulirovanie:
Ici, vous devez faire attention (dans la capture d'écran précédente) à l'étiquette de la paire de clés. Dans la terminologie PKCS # 11, il s'agit de l'attribut CKA_LABEL pour la clé publique et privée. C'est par un tel schéma qu'une étiquette (nom de clé) est créée par le générateur de requêtes EGAIS pour JaCarta à partir de CenterInform FSUE:
Traditionnellement triple
certificat x clé_ publique x clé privée
sur le jeton est connecté via l'
attribut CKA_ID
:
La façon la plus courante de spécifier CKA_ID consiste à utiliser la valeur de la fonction de hachage à partir de la valeur de la clé publique. C'est cette méthode de liaison d'un triple d'objets qui est utilisée dans le projet NSS (Network Security Services). En même temps, l'algorithme SHA1 est utilisé comme fonction de hachage.
Malheureusement, CKA_LABEL et CKA_ID peuvent être définis / modifiés à tout moment avec n'importe quelle valeur. Ainsi, il est toujours possible que le certificat soit associé à la clé privée d'une autre personne. Pas besoin d'expliquer quelles en seront les conséquences.
En général, existe-t-il un algorithme mathématique strict qui vous permet de connecter le triple CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY en un seul ensemble?
Oui, un tel algorithme basé sur les mécanismes cryptographiques (CKM_) du token
existe .
Malheureusement (bien que cela puisse être objectivement compris), il considère un tas dans un triple via CKA_LABEL, formé par la méthode susmentionnée. De plus, pour les clés privées et publiques, SKA_ID est formé de manière similaire. Pour les clés, c'est juste un désastre, car cependant ni CKA_ID ni CKA_LABEL ne sont liés de quelque façon à la clé elle-même. Cela s'applique également au certificat après son installation sur le jeton. Si dans la formation traditionnelle de CKA_ID en tant que hachage à partir de la clé publique, vous pouvez toujours vérifier si l'un correspond à l'autre, puis lors de la configuration de CKA_ID et CKA_LABEL de la manière décrite ci-dessus, cela ne peut pas être fait.
Une question peut se poser, mais comment vérifier la conformité d'une clé privée? La réponse est simple - en calculant la valeur de la clé publique par rapport à la clé privée. Quant au certificat, la valeur de sa clé publique y est, naturellement. De plus, le certificat lui-même contient la valeur CKA_ID à la fois pour le titulaire du certificat (identifiant de clé de sujet de certificat) et l'éditeur de certificat (identifiant de clé d'autorité de certification):
Le plus désagréable est que lors de l'installation du certificat, ce n'est pas la présence de la clé privée qui est vérifiée, mais seule la clé publique est suffisante. Dans ce cas, le certificat sera installé, mais il n'y aura pas de clé privée dessus. Un autre problème. Il s'agit d'une recherche de clé publique par TIN. Imaginez qu'une personne possède un NIF et plusieurs clés pour divers certificats. Lequel appartient? Après cela, il devient clair que JaCarta ne doit avoir
qu'un seul certificat et une seule paire de clés:
Cette erreur peut être liée à la duplication de certificats. Dans le client unique JaCarta en mode administrateur, sur l'onglet GOST Après avoir entré le code PIN, une clé publique, une clé privée et un certificat doivent être visibles. Dans ce cas, la duplication des clés est visible. Vous devez supprimer les supplémentaires. Réinsérez le support dans le connecteur USB et essayez de réinstaller l'UTM. Si l'erreur persiste, initialisez Jacarta selon le lien 1 et recommencez le processus de génération.
Espérons que cette lacune sera éliminée. Vous pouvez demander comment l'utilitaire cryptoarmpkcs pour EGAIS installe le certificat. Pour une compatibilité totale avec JaCarta, nous avons maintenu l'idéologie selon laquelle CKA_ID et CKA_LABEL pour les clés sont identiques. Mais seulement après avoir installé le certificat sur le jeton et l'avoir lié à la paire de clés. Jusque-là, la paire de clés CKA_ID est maintenue égale à la valeur de hachage de la clé publique.
Après avoir installé le certificat, vous pouvez l'utiliser pour
signer des documents .
Vous pouvez lire sur les certificats auto-signés
ici :
Les distributions sont au même endroit.