Stasiun kerja kriptografis berdasarkan token PKCS # 11. Memperoleh sertifikat untuk EGAIS. Bagian 4

Dan sekarang, ketika saya hampir menambahkan generasi sertifikat yang ditandatangani sendiri ke workstation kriptografi berdasarkan token cryptoarmpkcs PKCS # 11 dan siap untuk mulai menulis artikel, saya menerima surat seperti ini:

Kami adalah UZNIREK CA, kami mengalami kesulitan mengeluarkan ES dalam format pkcs # 11 untuk EGAIS, portal tidak memahami ES dalam format CSP Znamerek, kami meminta Anda untuk membantu dalam masalah ini.

Saya tidak tahu semua seluk-beluk bekerja dengan EGAIS, tetapi karena ini tentang PKCS # 11, saya menyarankan menggunakan utilitas cryptoarmpkcs untuk menghasilkan permintaan dan menginstal sertifikat untuk token setelah menerimanya dari CA Jawaban yang saya terima agak mengganggu:

Sayangnya, kenyataannya adalah bahwa kami mencatat ES pada RuToken 2.0 melalui CryptoPro CSP, tetapi dengan semua pengaturan yang tepat, portal EGAIS tidak melihat ES pada media utama, klien menghubungi kami untuk mendukung dan kami menemukan bahwa masalahnya bukan sertifikat kunci ditulis dalam format itu, di sini adalah manual dev.rutoken.ru/display/KB/RU1051

.
Saya (dan bukan hanya saya) sudah menulis berkali-kali bahwa banyak menggunakan token kriptografi dengan dukungan kriptografi Rusia sebagai flash drive biasa . Dan ini hanya terjadi ketika kunci dan sertifikat tidak sampai ke token sebagai objek PKCS # 11. Sayang sekali mereka tidak menerima saran dan bahkan tidak mencoba membuat permintaan. Tapi kemudian saya memutuskan untuk mengesampingkan semuanya dan mencari tahu bagaimana dan pada sertifikat apa EGAIS Rosalkogolregulirovanie dikeluarkan. Dan kami hanya akan mempertimbangkan token kriptografi PKCS # 11. Kekecewaan terbesar adalah akses ke EGAIS hanya melalui Windows dan browser IE. Di sisi lain, pembuatan permintaan sertifikat dan pemasangan sertifikat juga dapat dilakukan di bawah OS apa pun, jika memiliki driver / pustaka untuk token yang sesuai.

Setidaknya PKCS # 11 token JaCarta, RutokenECP-2.0, token perangkat lunak LS11SW2016 dan bahkan token cloud memiliki dukungan pada MS Windows, Linux, dan OS X. Dan tidak hanya pada OS ini.

Bahkan, kita harus membayar upeti kepada pengembang EGAIS. Mereka mengusulkan teknologi menarik yang memungkinkan akses untuk menggunakan sertifikat pribadi (sertifikat plus pasangan kunci) yang disimpan pada token kriptografi dengan dukungan untuk kriptografi Rusia, dan melindungi saluran pada sertifikat RSA. Meskipun jika mereka mengatakan A, maka orang bisa mengatakan B, yaitu melindungi saluran pada algoritma GOST-ov. Satu-satunya hal yang menyedihkan adalah bahwa semua ini hanya dirancang untuk MS Windows (atau saya salah?), Atau lebih tepatnya, untuk Internet Explorer. Dan utilitas untuk menghasilkan permintaan sertifikat untuk EGAIS terikat dengan token tertentu.

Tetapi utilitas cryptoarmpkcs adalah multi-platform. Selain itu, ia dapat bekerja dengan token kriptografi PKCS # 11 apa pun yang mendukung kriptografi Rusia.

Jadi, apa keanehan dari permintaan sertifikat untuk EGAIS? Fitur utama adalah kehadiran wajib dalam nama dibedakan dari pemegang sertifikat (subjek DN) dari bidang tambahan unstucturedName (UN) (oid - 1.2.840.113549.1.9.2). Jika pemilik sertifikat adalah pengusaha perorangan, maka baris “KPP =” ditulis di bidang ini, dan jika pemiliknya adalah badan hukum, maka baris ini ditulis di bidang ini:
PPC = reason_code_of_tax_account_account:



Dalam hal ini, persyaratan pada halaman pertama tab permintaan sertifikat telah ditambahkan tombol EGAIS:



Fitur lain adalah bahwa pemegang sertifikat untuk EGAIS dapat menjadi pemegang lisensi sistem deklarasi FSRAP (oid - 1.2.643.3.6.78.4.4). Ini juga perlu dipertimbangkan saat membuat permintaan:



Setelah semua bidang permintaan sertifikat selesai dan Anda telah mengkonfirmasi kebenaran data, pasangan kunci akan dibuat dan permintaan akan dibuat:



Jika Anda melihat permintaan, maka di dalamnya Anda dapat melihat oid-s (Penggunaan Kunci yang Diperpanjang), yang diperlukan untuk EGAIS Rosalkogolregulirovanie:



Di sini Anda harus memperhatikan (pada tangkapan layar sebelumnya) untuk label pasangan kunci. Dalam terminologi PKCS # 11, ini adalah atribut CKA_LABEL untuk kunci publik dan pribadi. Dengan skema seperti itulah label (nama kunci) dibuat oleh pembuat kueri EGAIS untuk JaCarta dari CenterInform FSUE:



Secara tradisional rangkap tiga sertifikat x public_key x kunci pribadi
pada token terhubung melalui atribut CKA_ID
:

Cara paling umum untuk menentukan CKA_ID adalah dengan menggunakan nilai fungsi hash dari nilai kunci publik. Ini adalah metode yang digunakan untuk menghubungkan triple objek dalam proyek NSS (Layanan Keamanan Jaringan). Pada saat yang sama, algoritma SHA1 digunakan sebagai fungsi hash.

Sayangnya, baik CKA_LABEL dan CKA_ID dapat disetel / diubah kapan saja dengan nilai apa pun. Dengan demikian, selalu ada kemungkinan bahwa sertifikat akan dikaitkan dengan kunci pribadi orang lain. Tidak perlu menjelaskan apa akibatnya nanti.

Secara umum, apakah ada algoritma matematika ketat yang memungkinkan Anda untuk menghubungkan triple CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY menjadi satu kesatuan?
Ya, algoritma seperti itu yang didasarkan pada mekanisme kriptografi (CKM_) dari token ada .

Sayangnya (meskipun dapat dipahami secara objektif), ia menganggap banyak dalam tiga hingga CKA_LABEL, yang dibentuk oleh metode yang disebutkan di atas. Selain itu, untuk kunci privat dan publik, SKA_ID dibentuk dengan cara yang serupa. Untuk kunci, ini hanya bencana, karena namun CKA_ID maupun CKA_LABEL tidak terikat dengan kunci apa pun. Ini juga berlaku untuk sertifikat setelah diinstal pada token. Jika dalam formasi tradisional CKA_ID sebagai hash dari kunci publik, Anda selalu dapat memeriksa apakah satu cocok dengan yang lain, maka ketika mengatur CKA_ID dan CKA_LABEL dengan cara yang dijelaskan di atas, ini tidak dapat dilakukan.

Sebuah pertanyaan mungkin muncul, tetapi bagaimana memeriksa kepatuhan terhadap kunci pribadi? Jawabannya sederhana - dengan menghitung nilai kunci publik terhadap kunci pribadi. Adapun sertifikat, nilai kunci publiknya, secara alami, ada di dalamnya. Selain itu, sertifikat itu sendiri berisi nilai CKA_ID untuk pemegang sertifikat (Pengidentifikasi Kunci Subjek Sertifikat) dan penerbit sertifikat (Pengidentifikasi Kunci Otoritas Sertifikat):



Hal yang paling tidak menyenangkan adalah ketika memasang sertifikat, bukan keberadaan kunci pribadi yang diperiksa, tetapi hanya kunci publik yang memadai. Dalam hal ini, sertifikat akan diinstal, tetapi tidak akan ada kunci pribadi di dalamnya. Masalah lain. Ini adalah pencarian kunci publik oleh TIN. Bayangkan seseorang memiliki satu TIN dan beberapa kunci untuk berbagai sertifikat. Milik siapa? Setelah itu, menjadi jelas persyaratan bagi JaCarta untuk hanya memiliki satu sertifikat dan satu pasangan kunci:

Kesalahan ini mungkin terkait dengan duplikasi sertifikat. Dalam JaCarta Single Client dalam mode administrator, pada tab GOST Setelah memasukkan kode PIN, satu publik, satu kunci pribadi dan sertifikat akan terlihat. Dalam hal ini, duplikasi kunci terlihat. Anda harus menghapus yang ekstra. Masukkan kembali media ke dalam konektor usb dan coba pasang kembali UTM. Jika kesalahan berlanjut, inisialisasi Jacarta sesuai dengan tautan 1 dan lanjutkan proses pembuatan lagi.

Semoga saja kekurangan ini bisa dihilangkan. Anda dapat bertanya bagaimana utilitas cryptoarmpkcs untuk EGAIS menginstal sertifikat. Untuk kompatibilitas penuh untuk JaCarta, kami telah mempertahankan ideologi bahwa CKA_ID dan CKA_LABEL untuk kunci adalah sama. Tetapi hanya setelah menginstal sertifikat pada token dan mengikatnya pada pasangan kunci. Hingga saat itu, pasangan kunci CKA_ID dijaga sama dengan nilai hash dari kunci publik.
Setelah menginstal sertifikat, Anda dapat menggunakannya untuk menandatangani dokumen .

Anda dapat membaca tentang sertifikat yang ditandatangani sendiri di sini :