والآن ، عندما أضفت تقريبًا توليد
الشهادات الموقعة ذاتياً إلى محطة عمل التشفير استنادًا إلى الرموز المميزة لـ PKCS # 11 cryptoarmpkcs وكنت مستعدًا لبدء كتابة المقالة ، تلقيت رسالة مثل هذا:
نحن UZNIREK CA ، واجهنا صعوبة في إصدار ES بتنسيق pkcs # 11 لـ EGAIS ، المدخل لا يفهم ES في تنسيق Znamerek CSP ، نطلب منك المساعدة في هذه المشكلة.
لم أكن أعلم كل تعقيدات العمل مع EGAIS ، لكن بما أنه كان PKCS # 11 ، فقد اقترحت استخدام الأداة المساعدة cryptoarmpkcs
لإنشاء طلب وتثبيت شهادة الرمز المميز بعد استلامها من المرجع المصدق. الإجابة التي تلقيتها كانت مشتتة إلى حد ما:
للأسف ، الحقيقة هي أننا سجلنا ES على RuToken 2.0 من خلال CryptoPro CSP ، ولكن مع كل الإعدادات المناسبة ، لم ترى بوابة EGAIS ES على الوسيط الرئيسي ، واتصل العميل بنا لدعم ووجدنا أن المشكلة ليست شهادة المفتاح مكتوبة بهذا التنسيق ، وهنا هو دليل dev.rutoken.ru/display/KB/RU1051
.
لقد كتبت (وليس أنا فقط) مرات عديدة أن العديد منهم يستخدمون الرموز المشفرة بدعم من التشفير الروسي كمحركات
أقراص فلاش عادية . وكان هذا هو الحال عندما لم يصل المفتاح والشهادة إلى الرمز المميز ككائنات PKCS # 11. من العار أنهم لم يأخذوا النصيحة ولم يحاولوا حتى إنشاء طلب. لكنني قررت بعد ذلك وضع كل شيء جانباً ومعرفة كيفية إصدار شهادات EGAIS Rosalkogolregulirovanie وماهية الشهادات. وسوف ننظر فقط الرموز PKCS # 11 التشفير. أكبر خيبة أمل هي الوصول إلى EGAIS فقط من خلال Windows ومتصفح IE. من ناحية أخرى ، يمكن أيضًا إنشاء طلب شهادة وتثبيت الشهادة تحت أي نظام تشغيل ، إذا كان لديه برامج تشغيل / مكتبات للرمز المقابل.
على الأقل PKCS # 11 ترمز إلى JaCarta و RutokenECP-2.0 و LS11SW2016 الرمز المميز للبرنامج وحتى
الرمز المميز السحابي لديهم دعم على MS Windows و Linux و OS X. وليس فقط على أنظمة التشغيل هذه.
في الواقع ، يجب أن نشيد بمطوري EGAIS. اقترحوا تقنية مثيرة للاهتمام تتيح الوصول إلى استخدام الشهادات الشخصية (شهادة بالإضافة إلى زوج المفاتيح) المخزنة على الرموز المشفرة مع دعم للتشفير الروسي ، وحماية القناة على شهادات RSA. على الرغم من أنهم إذا قالوا A ، يمكن للمرء أن يقول B ، أي حماية القناة على خوارزميات GOST-ov. الشيء المحزن الوحيد هو أن كل هذا مصمم فقط لـ MS Windows (أو أنا مخطئ؟) ، أو بالأحرى ، لمتصفح Internet Explorer. ترتبط الأدوات المساعدة لإنشاء طلبات الشهادة لـ EGAIS برمز مميز.
لكن الأداة cryptoarmpkcs متعددة المنصات. علاوة على ذلك ، فإنه قادر على العمل مع أي رمز تشفير PKCS # 11 يدعم التشفير الروسي.
إذن ، ما هي خصوصية طلب الشهادة لـ EGAIS؟ الميزة الرئيسية هي الوجود الإلزامي في الاسم المميز لحامل الشهادة (موضوع DN) لحقل إضافي بدون اسم (UN) (oid - 1.2.840.113549.1.9.2). إذا كان مالك الشهادة منظمًا فرديًا ، فسيتم كتابة السطر "KPP =" في هذا الحقل ، وإذا كان المالك كيانًا قانونيًا ، تتم كتابة سطر من النوع التالي في هذا الحقل:
تكلفة النقرة = reason_code_of_tax_account_account:
في هذا الصدد ، تمت إضافة المتطلبات على الصفحة الأولى من علامة تبويب طلب الشهادة زر EGAIS:
ميزة أخرى هي أن حاملي شهادات EGAIS يمكن أن يكونوا مرخصين لنظام إعلان FSRAP (oid - 1.2.643.3.6.78.4.4). يجب أيضًا مراعاة ذلك عند إنشاء طلب:
بعد ملء جميع حقول طلب الشهادة وتأكيد صحة البيانات ، سيتم إنشاء زوج مفاتيح وسيتم إنشاء الطلب:
إذا نظرت إلى الطلب ، فبإمكانك أن ترى فيه oid-s (استخدام مفتاح Extetnded) ، وهي مطلوبة لـ EGAIS Rosalkogolregulirovanie:
هنا يجب الانتباه (في لقطة الشاشة السابقة) إلى ملصق زوج المفاتيح. في مصطلحات PKCS # 11 ، هذه هي سمة CKA_LABEL للمفتاح العام والخاص. يتم إنشاء تسمية (اسم المفتاح) بواسطة مُنشئ استعلام EGAIS لـ JaCarta من CenterInform FSUE:
تقليديًا ،
الشهادة الثلاثية
x public_key x المفتاح الخاص
على الرمز المميز متصل من خلال
السمة CKA_ID
:
الطريقة الأكثر شيوعًا لتحديد CKA_ID هي استخدام قيمة دالة التجزئة من قيمة المفتاح العمومي. هذه هي الطريقة لربط ثلاثة كائنات يتم استخدامها في مشروع NSS (خدمات أمان الشبكة). في نفس الوقت ، يتم استخدام خوارزمية SHA1 كدالة تجزئة.
لسوء الحظ ، يمكن ضبط / تغيير كل من CKA_LABEL و CKA_ID في أي وقت وبأي قيمة. وبالتالي ، هناك دائمًا احتمال ربط الشهادة بالمفتاح الخاص لشخص آخر. لا حاجة لشرح ما ستكون عواقب هذا.
بشكل عام ، هل هناك خوارزمية رياضية صارمة تسمح لك بتوصيل CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY الثلاثية؟
نعم ، توجد خوارزمية تستند إلى آليات التشفير (CKM_) للرمز المميز.
لسوء الحظ (على الرغم من أنه يمكن فهمه بشكل موضوعي) ، إلا أنه يعتبر مجموعة من ثلاثة أضعاف خلال CKA_LABEL ، المشكلة بالطريقة المذكورة أعلاه. علاوة على ذلك ، بالنسبة للمفاتيح الخاصة والعامة ، يتم تشكيل SKA_ID بطريقة مماثلة. بالنسبة للمفاتيح ، هذه مجرد كارثة ، لأن ومع ذلك ، لا يرتبط CKA_ID أو CKA_LABEL بأي شكل من الأشكال بالمفتاح نفسه. ينطبق هذا أيضًا على الشهادة بعد تثبيتها على الرمز المميز. إذا كان في التكوين التقليدي لـ CKA_ID كتجزئة من المفتاح العمومي ، فيمكنك دائمًا التحقق مما إذا كان أحدهما يطابق الآخر ، ثم عند تعيين CKA_ID و CKA_LABEL بالطريقة الموضحة أعلاه ، لا يمكن القيام بذلك.
قد ينشأ سؤال ، ولكن كيف يمكن التحقق من الامتثال لمفتاح خاص؟ الجواب بسيط - عن طريق حساب قيمة المفتاح العمومي مقابل المفتاح الخاص. بالنسبة للشهادة ، تكون قيمة المفتاح العمومي فيها طبيعية. علاوة على ذلك ، تحتوي الشهادة نفسها على قيمة CKA_ID لكل من حامل الشهادة (معرف مفتاح موضوع الشهادة) وناشر الشهادة (معرف مفتاح مرجع الشهادة):
كان أكثر الأشياء غير السارة أنه عند تثبيت الشهادة ، لم يكن وجود المفتاح الخاص هو الذي تم تحديده ، ولكن فقط المفتاح العمومي يكفي. في هذه الحالة ، سيتم تثبيت الشهادة ، ولكن لن يكون هناك مفتاح خاص بها. مشكلة اخرى هذا بحث عن مفتاح عام بواسطة TIN. تخيل أن الشخص لديه رقم تعريف شخصي واحد وعدة مفاتيح لشهادات مختلفة. أي واحد ينتمي؟ بعد ذلك ، يصبح من الواضح أن JaCarta لديها
شهادة واحدة فقط وزوج مفتاح واحد:
قد يرتبط هذا الخطأ بتكرار الشهادة. في JaCarta Single Client في وضع المسؤول ، في علامة تبويب GOST بعد إدخال رمز PIN ، يجب أن يكون مفتاح عام وشخص واحد وشهادة مرئية. في هذه الحالة ، الازدواجية الرئيسية مرئية. تحتاج إلى إزالة إضافية منها. أعد إدخال الوسائط في موصل USB وحاول تثبيت UTM مرة أخرى. إذا استمر الخطأ ، فقم بتهيئة Jacarta وفقًا للرابط 1 واستمر في عملية التوليد مرة أخرى.
دعونا نأمل أن يتم القضاء على هذا القصور. قد تسأل كيف تقوم الأداة المساعدة cryptoarmpkcs لـ EGAIS بتثبيت الشهادة. للتوافق التام مع JaCarta ، حافظنا على الإيديولوجية التي تتشابه في CKA_ID و CKA_LABEL للمفاتيح. ولكن فقط بعد تثبيت الشهادة على الرمز المميز وربطها في زوج المفاتيح. حتى ذلك الحين ، يتم الاحتفاظ زوج المفاتيح CKA_ID بالتساوي مع قيمة التجزئة من المفتاح العمومي.
بعد تثبيت الشهادة ، يمكنك استخدامها
لتوقيع المستندات .
يمكنك أن تقرأ عن الشهادات الموقعة ذاتيا
هنا :
