ใบรับรองซอฟต์รูทของ Lissy ส่วนวิกิ

ความต้องการของระบบ

• อินเทอร์เน็ต
• ระบบปฏิบัติการ: Windows 8, 7, XP SP 3/2
• หน่วยประมวลผล: 1.6 GHz หรือสูงกว่า
• RAM: 512 MB
• ความพร้อมใช้งานของหนึ่งในผู้ให้บริการเข้ารหัสที่รองรับ: CryptoPro CSP 3.6 หรือสูงกว่า, LISSI CSP, VIPNet CSP, Signal-COM CSP
• ความละเอียดหน้าจอ: อย่างน้อย 800x600 px

ใช้ผู้ให้บริการเข้ารหัสลับที่ผ่านการรับรอง

สำหรับการทำงานของโปรแกรม Ekey.Signature การมีอยู่ในสถานที่ทำงานของเครื่องมือป้องกันข้อมูลเข้ารหัส (CIPF) ที่เข้ารหัสเอกสารตามอัลกอริทึม GOST เป็นสิ่งจำเป็น ระบบ CryptoPro CSP ไม่ต่ำกว่า 3.6, LISSI CSP, VIPNet CSP, Signal-COM CSP สามารถใช้เป็น CIPF ได้

เครื่องมือป้องกันข้อมูลการเข้ารหัสเข้ากันได้กับ Ekey.Signature แต่เข้ากันไม่ได้ สามารถติดตั้ง CIPF ได้เพียงแห่งเดียวในที่ทำงานแห่งเดียว

ใช้โปรแกรมป้องกันไวรัส

ติดตั้งโปรแกรมป้องกันไวรัสยอดนิยมในที่ทำงานของคุณและอัปเดตเป็นประจำ แอนติไวรัสป้องกันไวรัส สปายแวร์ และกำจัดภัยคุกคามความปลอดภัยส่วนใหญ่ด้วยตัวมันเอง

ปกป้องการเข้าถึงลายเซ็นอิเล็กทรอนิกส์และสถานที่ทำงานของคุณด้วยรหัสผ่าน

ด้วยการใช้เครื่องมือป้องกัน Ekey.Signature และการเข้ารหัส ปกป้องคอมพิวเตอร์ของคุณจากการเข้าถึงทางกายภาพจากคนแปลกหน้า ใช้การเข้าถึงรหัสผ่าน

ในการเข้าถึง ลายเซนต์อิเล็กทรอนิกส์, ใช้รหัสผ่านที่ซับซ้อน รหัสผ่านที่ดีคือการรับประกันความปลอดภัยของข้อมูลของคุณ วิธีที่ดีในการจำรหัสผ่านคือการป้อนรหัสผ่านอย่างต่อเนื่องเมื่อดำเนินการกับลายเซ็นอิเล็กทรอนิกส์

สถานที่ที่ดีในการจัดเก็บรหัสผ่านของคุณคือหน่วยความจำของคุณ ไม่แนะนำให้จดรหัสผ่านไว้ที่ใด อย่าเก็บรหัสผ่านไว้ใกล้กับผู้ให้บริการลายเซ็นอิเล็กทรอนิกส์จริง อย่าเก็บรหัสผ่านไว้ในระบบ

ใช้เฉพาะโปรแกรมที่ได้รับอนุญาตและเป็นปัจจุบัน

โปรแกรมที่ติดตั้งในที่ทำงานของคุณจะได้รับการอัปเดตเป็นระยะๆ เพื่อปรับปรุงความเสถียรและความปลอดภัยของงานของคุณ

ติดตั้งการอัปเดตซอฟต์แวร์จากเว็บไซต์อย่างเป็นทางการเท่านั้น ตรวจสอบที่อยู่เว็บไซต์และข้อมูลเกี่ยวกับผู้เผยแพร่โปรแกรมก่อนทำการติดตั้ง

การติดตั้ง Ekey ลายเซ็น

1. ดาวน์โหลด

2. ในการเริ่มการติดตั้งโปรแกรม ให้เรียกใช้ไฟล์ติดตั้ง หากเปิดใช้ UAC คุณต้องอนุญาตการเปลี่ยนแปลงโปรแกรม Ekey Transfer

การเตรียมไฟล์สำหรับ Rosreestr

1. เลือกประเภทการดำเนินการ "Rosreestr" ในหน้าต่างโปรแกรมหลักหรือในเมนูบริบทของไฟล์

3. เพิ่มรายงานโดยใช้ปุ่ม "แนบไฟล์" หรือลากและวางไฟล์โดยใช้เมาส์
4. คลิกปุ่มสร้าง
6. หลังจากดำเนินการเสร็จสิ้น ไฟล์ลายเซ็นจะถูกบันทึกลงในไดเร็กทอรีเดียวกันกับไฟล์ต้นฉบับ ไฟล์ลายเซ็นที่แยกออกมาจะมีผลก็ต่อเมื่อมีไฟล์ต้นฉบับอยู่

การเตรียมตู้คอนเทนเนอร์สำหรับ FFMS ของรัสเซีย, บริการของธนาคารแห่งรัสเซีย, ธนาคารกลาง

1. เลือกประเภทของการดำเนินการ "FFMS ของรัสเซีย"

2. เลือกใบรับรองส่วนบุคคล

3. เพิ่มรายงานที่มีนามสกุล xtdd หรือ smcl โดยใช้ปุ่ม "แนบไฟล์" หรือลากและวางไฟล์ด้วยเมาส์

5. หากจำเป็น ให้ป้อนรหัสผ่านสำหรับคอนเทนเนอร์คีย์ส่วนตัว

7. หากต้องการเพิ่มลายเซ็น ให้แนบคอนเทนเนอร์ที่สร้างไว้ก่อนหน้านี้ เลือกใบรับรองที่ต้องการแล้วคลิกปุ่มสร้าง

8. ในการส่งรายงานไปยังพอร์ทัลของ Bank of Russia Service (FFMS) ให้คลิกปุ่มเพิ่ม ในเมนูที่ปรากฏขึ้น เลือกคอนเทนเนอร์ที่ต้องการพร้อมกับรายงาน แล้วคลิกปุ่มอัปโหลดไปยังพอร์ทัล

FSIS TP กระทรวงการพัฒนาภูมิภาคของรัสเซีย

1. เลือกประเภทของการดำเนินการ "FSIS TP"

2. เลือกใบรับรองส่วนบุคคล

3. เพิ่มรายงานโดยใช้ปุ่ม "แนบไฟล์" หรือลากและวางไฟล์โดยใช้เมาส์

4. คลิกปุ่มสร้าง

5. หากจำเป็น ให้ป้อนรหัสผ่านสำหรับคอนเทนเนอร์คีย์ส่วนตัว

6. ในเมนูบันทึกที่ปรากฏขึ้น ให้เลือกตำแหน่งที่จะบันทึกผลการดำเนินการ

ทะเบียน Roskomnadzor (zapret-info.gov.ru)

1. เลือกการดำเนินการของรีจิสทรี Roskomnadzor

2. เลือกใบรับรองส่วนบุคคล

3. หากต้องการทราบเวลาของการอัปเดตล่าสุดของรีจิสทรี ให้คลิก "เวลาของการอัปเดตล่าสุดของการยกเลิกการโหลดจากรีจิสทรี"

4. หากต้องการส่งคำขอ ให้คลิก "ส่งคำขอ"

กรอกข้อมูลในฟิลด์เพื่อสร้างคำขอ

5. หากต้องการรับผลการดำเนินการตามคำขอ ให้คลิก "ขอเพื่อรับผลลัพธ์"

ในการยกเลิกการโหลดรีจิสทรีโดยอัตโนมัติ คุณต้องทำเครื่องหมายในช่อง "ยกเลิกการโหลดโดยอัตโนมัติ" กำหนดระยะเวลาที่จำเป็นสำหรับการขนถ่ายและระบุไดเรกทอรีเพื่อบันทึกผลลัพธ์ของการขนถ่าย

ISED

1. เลือกประเภทการดำเนินการ "ISED"

2. เพิ่มรายงานโดยใช้ปุ่ม "แนบไฟล์" หรือลากและวางไฟล์โดยใช้เมาส์

3. เลือกใบรับรองผู้รับ

4. คลิกปุ่มสร้าง

5. ในเมนูบันทึกที่ปรากฏขึ้น ให้เลือกตำแหน่งที่จะบันทึกผลการดำเนินการ

ลายเซ็นไฟล์

1. เลือกประเภทการดำเนินการ "ลงชื่อด้วยตนเอง"

2. เลือกใบรับรองส่วนบุคคล

4. เลือกตัวเลือกลายเซ็นที่ต้องการ

5. คลิกปุ่ม "ลงชื่อเข้าใช้"

6. หากจำเป็น ให้ป้อนรหัสผ่านสำหรับคอนเทนเนอร์คีย์ส่วนตัว

คำอธิบาย:

บันทึกลายเซ็นในไฟล์แยกต่างหาก

เมื่อตั้งค่าสถานะแล้ว ลายเซ็นอิเล็กทรอนิกส์ที่ไม่มีการตรึงจะถูกสร้างขึ้นหากไม่มีแฟล็ก ลายเซ็นจะถูกเพิ่มที่ส่วนท้ายของไฟล์ (ในกรณีนี้ เอกสารและลายเซ็นอิเล็กทรอนิกส์จะถูกจัดเก็บไว้ด้วยกัน)

ไฟล์เก็บถาวร

ฉันจำเป็นต้องเก็บถาวรไฟล์หลังจากลงนามหรือไม่

การขยาย - นามสกุลไฟล์ลายเซ็นเริ่มต้นคือ sig คุณสามารถระบุนามสกุลของคุณเองได้

การเข้ารหัส - เลือกการเข้ารหัสที่คุณต้องการ Der หรือ Base-64

ปิดการใช้งานส่วนหัวของบริการ- หากเลือกการเข้ารหัส Base-64 (ส่วนหัวจะใช้เพื่อความเข้ากันได้กับบุคคลที่สาม ซอฟต์แวร์).

การเข้ารหัสไฟล์

1. เลือกประเภทการดำเนินการ "เข้ารหัสด้วยตนเอง"

2. เลือกใบรับรองส่วนบุคคล

3. เพิ่มไฟล์โดยใช้ปุ่ม "แนบไฟล์" หรือลากและวางไฟล์โดยใช้เมาส์

4. เลือกตัวเลือกการเข้ารหัสที่จำเป็น

5. เพิ่มหรือเลือกจากใบรับรองผู้รับที่มีอยู่ (ไฟล์จะถูกเข้ารหัส)

6. คลิกปุ่ม "เข้ารหัส"

7. หากจำเป็น ให้ป้อนรหัสผ่านสำหรับคอนเทนเนอร์คีย์ส่วนตัว

8. ในเมนูบันทึกที่ปรากฏขึ้น ให้เลือกตำแหน่งที่จะบันทึกผลการดำเนินการ คำอธิบาย:

การเข้ารหัส

เลือกการเข้ารหัส Der หรือ Base-64 ที่คุณต้องการ

การขยาย

นามสกุลที่ไฟล์สุดท้ายจะมี (enc โดยค่าเริ่มต้น) คุณยังสามารถระบุนามสกุลของคุณเองได้ ปิดใช้งานส่วนหัวของบริการ - หากเลือกการเข้ารหัส Base-64 (จำเป็นสำหรับความเข้ากันได้กับซอฟต์แวร์ของบริษัทอื่น)

เก็บถาวรไฟล์ก่อนการเข้ารหัส

หากคุณต้องการเก็บถาวรไฟล์ก่อนการเข้ารหัส ให้เลือกช่องที่เหมาะสม

หากคุณเพิ่มหลายไฟล์ ไฟล์ทั้งหมดจะถูกรวมเป็นไฟล์เดียว

ไฟล์ถอดรหัส

1. เลือกประเภทการดำเนินการ "ถอดรหัส"

2. เลือกใบรับรองส่วนบุคคล

3. เพิ่มไฟล์โดยใช้ปุ่ม "แนบไฟล์" หรือลากและวางไฟล์โดยใช้เมาส์

4. คลิกปุ่ม "ถอดรหัส"

5. หากจำเป็น ให้ป้อนรหัสผ่านสำหรับคอนเทนเนอร์คีย์ส่วนตัว

6. ในเมนูบันทึกที่ปรากฏขึ้น ให้เลือกตำแหน่งที่จะบันทึกผลการดำเนินการ

การตรวจสอบลายเซ็น

1. ในการเริ่มตรวจสอบลายเซ็น ให้ใช้วิธีการยืนยันที่คุณสะดวก

• โดยดับเบิลคลิกที่ไฟล์ที่มีลายเซ็น
• เลือกประเภทการทำงาน "ยืนยันลายเซ็น" ในเมนูหลักของโปรแกรม
• ผ่านเมนูบริบทของไฟล์ที่จะตรวจสอบ

2. เพิ่มไฟล์โดยใช้ปุ่ม "แนบไฟล์" หรือลากและวางไฟล์โดยใช้เมาส์

3. คลิกปุ่มตรวจสอบ

หลังจากคลิกปุ่ม "ตรวจสอบ" หน้าต่างจะปรากฏขึ้นพร้อมกับผลการตรวจสอบลายเซ็น ในนั้น คุณสามารถดูแผนผังลายเซ็น พิมพ์ผลการตรวจสอบ และเปิดไฟล์ต้นฉบับเพื่อดูได้

นอกจากนี้ ในระหว่างการสแกน คุณสามารถดูเนื้อหาของไฟล์ที่มีนามสกุล: doc xls csv pdf html htm txt xml zip png jpeg jpg bmp gif

คำอธิบาย:

ยกเลิกการลงชื่อไฟล์

หากมีการสร้างลายเซ็นที่แนบมา คุณสามารถใช้ตัวเลือกนี้เพื่อรับไฟล์ต้นฉบับที่ไม่มีลายเซ็นใดๆ

เพิ่มลายเซ็น

1. เลือกประเภทของการดำเนินการ "เพิ่มลายเซ็น"

2. เลือกใบรับรองส่วนบุคคล

4. คลิกปุ่ม "ลงชื่อเข้าใช้"

5. หากจำเป็น ให้ป้อนรหัสผ่านสำหรับคอนเทนเนอร์คีย์ส่วนตัว

6. ในเมนูบันทึกที่ปรากฏขึ้น ให้เลือกตำแหน่งที่จะบันทึกผลการดำเนินการ

ตรวจสอบลายเซ็น

1. เลือกประเภทการดำเนินการ "รับรองลายเซ็น"

2. เลือกใบรับรองส่วนบุคคล

3. เพิ่มไฟล์ลายเซ็นโดยใช้ปุ่ม "แนบไฟล์" หรือลากและวางไฟล์โดยใช้เมาส์

4. คลิกปุ่มยืนยัน

5. หากจำเป็น ให้ป้อนรหัสผ่านสำหรับคอนเทนเนอร์คีย์ส่วนตัว

6. ในเมนูที่ปรากฏขึ้น เลือกลายเซ็นที่คุณต้องการรับรอง

7. ในเมนูบันทึกที่ปรากฏขึ้น ให้เลือกตำแหน่งที่จะบันทึกผลการดำเนินการ

อัพเดทอัตโนมัติ

เมื่อมีการอัพเดท คำจารึกที่เกี่ยวข้องจะปรากฏขึ้นที่มุมขวาบนของแอปพลิเคชั่น Ekey Signature ที่เปิดใช้งาน ในการเริ่มการอัปเดต ให้คลิกที่ปุ่มซ้ายของเมาส์

หลังจากกระบวนการอัปเดตเสร็จสิ้น คลิก "ตกลง" ที่ข้อความว่าการเปลี่ยนแปลงบางอย่างจะมีผลหลังจากรีบูตเท่านั้น คลิกปุ่ม "เสร็จสิ้น" หลังจากนั้นขอแนะนำให้รีสตาร์ทคอมพิวเตอร์ จำเป็นต้องมีการรีบูตก่อนเพื่อให้การอัปเดตที่เกี่ยวข้องกับการทำงานของเมนูบริบทของ Windows มีผล

การติดตั้งใบรับรองหลักโดยอัตโนมัติ

หากไม่มีใบรับรองหลักในร้านค้า เมื่อเปิดแอปพลิเคชัน Ekey Signature ข้อผิดพลาดที่เกี่ยวข้องจะแสดงในบันทึกของผู้ใช้ ในกรณีนี้ คุณควรเซ็นชื่อไฟล์ด้วยใบรับรองส่วนบุคคลที่ "มีปัญหา" เมื่อดำเนินการลงนาม กล่องโต้ตอบจะปรากฏขึ้นเพื่อขอให้คุณติดตั้งใบรับรองหลักที่ขาดหายไป คลิกใช่เพื่อติดตั้งใบรับรองหลักที่ขาดหายไป

ผู้ออกใบรับรอง CAFL63สร้างขึ้นบนพื้นฐานของ SQLite3 DBMS ใช้เพื่อเก็บข้อมูล (คำขอ ใบรับรอง การตั้งค่า ฯลฯ) หน่วยงานออกใบรับรองมีส่วนต่อประสานกราฟิกที่พัฒนาขึ้นใน Tcl/Tk

CAFL63 CA ได้รับการพัฒนาโดยคำนึงถึงข้อกำหนดของกฎหมายของรัฐบาลกลางลงวันที่ 6 เมษายน 2011 ฉบับที่ หมายเลข 63-FZ "ในลายเซ็นอิเล็กทรอนิกส์" เช่นเดียวกับ "ข้อกำหนดสำหรับแบบฟอร์ม ใบรับรองที่ผ่านการรับรองกุญแจสำหรับการตรวจสอบลายเซ็นอิเล็กทรอนิกส์” ได้รับอนุมัติโดยคำสั่งของ Federal Security Service ของรัสเซีย ลงวันที่ 27 ธันวาคม 2011 หมายเลข 795

CA รวมถึงศูนย์การลงทะเบียน (CR) ซึ่งรับผิดชอบในการรับใบสมัครสำหรับใบรับรองจากพลเมือง ปัจจุบันมีการออกใบรับรองสำหรับนิติบุคคล บุคคลธรรมดา และผู้ประกอบการรายบุคคล เปิดรับสมัครแล้วใน ในรูปแบบอิเล็กทรอนิกส์ในรูปแบบ PKCS#10, CSR (Certificate Signing Request) หรือ SPKAC โปรดทราบว่ารูปแบบ CSR เป็นคำขอที่เข้ารหัส PKCS#10 PEM โดยมีส่วนหัว -----BEGIN REQUEST CERTIFICATE-----

คำขอเป็นแบบสอบถามที่เสร็จสมบูรณ์ วัตถุประสงค์ที่ต้องการใบรับรอง กุญแจสาธารณะของผู้ใช้ รับรอง (ลงนาม) ด้วยรหัสส่วนตัวของผู้ใช้ นอกจากนี้ด้วยแพ็คเกจเอกสารรับรองโดยเฉพาะตัวตนของผู้ยื่นคำร้องและสื่ออิเล็กทรอนิกส์ที่จัดเก็บคำขอ (ขอย้ำว่าขอเก็บไพรเวทคีย์ไว้ที่อื่นดีกว่า) พลเมืองมา ถึง CR CA

CR ตรวจสอบเอกสาร คำขอ (ข้อมูลที่กรอก ความถูกต้องของลายเซ็นอิเล็กทรอนิกส์ ฯลฯ) และหากทุกอย่างเป็นไปด้วยดี พวกเขาจะยอมรับคำขอ อนุมัติ และโอนไปยังศูนย์การรับรอง (CA)

กรณีผู้ยื่นคำร้องมาโดยไม่ได้รับคำร้องพร้อมๆ กับพนักงาน CR แยกย้ายกันไป ที่ทำงานที่มีการเตรียมคำขอใบรับรอง เตรียมคำขอสำหรับ สื่ออิเล็กทรอนิกส์ดังที่ได้กล่าวไปแล้ว เข้าสู่ CR ผู้สมัครต้องจำอะไรที่นี่? ก่อนอื่น: ผู้สมัครต้องรับสื่อด้วยรหัสส่วนตัวที่สร้างขึ้น!

คำขอที่ได้รับอนุมัติเกี่ยวกับสื่ออิเล็กทรอนิกส์จะถูกส่งไปยัง CA โดยจะมีการออกใบรับรองตามเกณฑ์

นี่คือแผนภาพพื้นฐานของงานของ UC รายละเอียดจะชัดเจนด้านล่าง หมายเหตุหนึ่ง เพื่อความสะดวกในการสาธิตยูทิลิตี้การเตรียมคำขอ CR และ CA จะรวมกันเป็นคอมเพล็กซ์สาธิตเดียว แต่ไม่มีปัญหาเรื่องการแยกฟังก์ชัน วิธีแก้ปัญหาที่ง่ายที่สุดคือการมีสำเนา CAFL63 ในสถานที่ทำงานแต่ละแห่ง และใช้ฟังก์ชันที่จำเป็นเท่านั้น

เมื่อโปรเจ็กต์เต็มไปหมด โปรเจ็กต์ SimpleCA ก็สะดุดตาฉัน การศึกษาโครงการนี้มีประโยชน์มากในการใช้งาน CAFL63 CA ขั้นสุดท้าย

ดาวน์โหลดการแจกจ่าย CAFL63 สำหรับแพลตฟอร์ม Win32/Win64, Linux_x86/Linux_x86_64

ดังนั้นเราจึงเปิดตัวยูทิลิตี้ CAFL63 - หน้าเริ่มต้น CAFL63 ปรากฏบนหน้าจอ:

เราเริ่มทำงานโดยกดปุ่ม "สร้างฐานข้อมูล" ฐานข้อมูล CA ถูกสร้างขึ้นโดยใช้ DBMS ข้ามแพลตฟอร์มของ SQLite3 ฐานข้อมูล CA มีหลายตาราง ตารางหลัก - mainDB - มีรายการเดียวเท่านั้น ซึ่งเก็บใบรับรองหลัก คีย์ส่วนตัวที่เข้ารหัสด้วยรหัสผ่าน และการตั้งค่า CA มีสองตารางที่เกี่ยวข้องกับคำขอใบรับรอง: คำขอปัจจุบันของ reqDB และที่เก็บคำขอ reqDBArc มีการสร้างตารางสามตารางสำหรับใบรับรอง: ตารางใบรับรองใหม่ certDBNew ตารางที่เก็บใบรับรอง CertDB และตารางการเพิกถอนใบรับรอง CertDBRev ตารางคำขอและใบรับรองทั้งหมดใช้ค่าแฮช (sha1) ของคีย์สาธารณะเป็นคีย์หลัก วิธีนี้สะดวกมาก เช่น เมื่อค้นหาใบรับรองตามต้องการหรือในทางกลับกัน มีตาราง crlDB อื่นในฐานข้อมูล ซึ่งเก็บรายการใบรับรองที่ถูกเพิกถอน ดังนั้นเราจึงคลิกปุ่ม "สร้างฐานข้อมูล":

การสร้าง CA เริ่มต้นด้วยการเลือกไดเร็กทอรีที่เราจะจัดเก็บฐานข้อมูลและตั้งรหัสผ่านเพื่อเข้าถึงคีย์ส่วนตัวของ CA โดยการกดปุ่ม "ถัดไป" เราจะไปที่หน้าสำหรับเลือกประเภทและพารามิเตอร์ของคู่คีย์สำหรับ CA:

เมื่อตัดสินใจเลือกคู่คีย์สำหรับใบรับรองรูทของผู้ออกใบรับรองที่ถูกสร้างขึ้น เราดำเนินการกรอกแบบฟอร์มพร้อมข้อมูลเกี่ยวกับเจ้าของ (เราข้ามภาพหน้าจอแรก):

โปรดทราบว่ายูทิลิตี้ CAFL63 มี "ความฉลาด" บางอย่างและดังนั้นจึงควบคุมไม่เพียง แต่การปรากฏตัวของข้อมูลในฟิลด์ แต่ยังรวมถึงความถูกต้อง (ไฮไลต์สีแดง - ไม่ถูกต้อง) ของการกรอกข้อมูลในฟิลด์เช่น TIN, OGRN, SNILS, OGRNIP, ที่อยู่ อีเมลและอื่น ๆ.

หลังจากกรอกข้อมูลในฟิลด์เกี่ยวกับเจ้าของ CA แล้ว คุณจะถูกขอให้ตัดสินใจเกี่ยวกับการตั้งค่าระบบของ CA:

หากคุณจะไม่ทำงานกับการเข้ารหัสภาษารัสเซีย คุณสามารถใช้ OpenSSL ปกติได้ ในการทำงานกับการเข้ารหัสของรัสเซีย คุณต้องระบุเวอร์ชันที่เหมาะสม การแก้ไขของ OpenSSL อ่าน README.txt ในการแจกจ่ายที่ดาวน์โหลดสำหรับรายละเอียดเพิ่มเติม นอกจากนี้ ตาม FZ-63 ได้เสนอให้ตั้งค่าข้อมูลเกี่ยวกับการรับรองของ CA เองและ CIPF ที่ใช้

หลังจากกรอกข้อมูลครบทุกช่องแล้ว ระบบจะขอให้คุณตรวจสอบความถูกต้องอีกครั้งแล้วคลิกปุ่ม "เสร็จสิ้น":

หลังจากคลิกปุ่ม "เสร็จสิ้น" ฐานข้อมูล CA จะถูกสร้างขึ้น ซึ่งจะบันทึกสิ่งต่อไปนี้: ใบรับรองหลักของ CA คีย์ส่วนตัว การตั้งค่าระบบ และหน้าเริ่มต้นของยูทิลิตี้ CAFL63 จะปรากฏขึ้นอีกครั้งบนหน้าจอ ตอนนี้เราได้สร้างฐานข้อมูลของ CA ที่สร้างขึ้นใหม่แล้ว เรากดปุ่ม "เปิดฐานข้อมูล" เลือกไดเร็กทอรีที่มีฐานข้อมูลและเข้าสู่หน้าต่างการทำงานหลักของ CA:

การคลิกปุ่ม "ดู CA CA" เราแน่ใจว่านี่คือใบรับรองหลักของเรา

ขั้นตอนต่อไปคือการจัดเตรียมเทมเพลต/โปรไฟล์การสมัครสำหรับนิติบุคคล บุคคล และผู้ประกอบการแต่ละราย ( เครื่องมือ->การตั้งค่า->ประเภทใบรับรอง->ใหม่ ):

หลังจากตั้งชื่อโปรไฟล์ใหม่แล้ว คุณจะได้รับแจ้งให้กำหนดองค์ประกอบของโปรไฟล์:

หลังจากเตรียมโปรไฟล์แล้ว CA ก็พร้อมที่จะรับผู้สมัครและใบสมัครจากพวกเขา ตามที่ระบุไว้ข้างต้น ผู้สมัครสามารถมาพร้อมกับหรือไม่มีใบสมัครที่สมบูรณ์สำหรับใบรับรอง

หากผู้สมัครมาพร้อมกับใบสมัครที่กรอกแล้ว หลังจากตรวจสอบเอกสารแล้ว ใบสมัครจะถูกนำเข้าไปยังฐานข้อมูลของ CA ในการดำเนินการนี้ ในหน้าต่างการทำงานหลัก ให้เลือกแท็บ "คำขอใบรับรอง" คลิกปุ่ม "นำเข้าคำขอ / CSR" และเลือกไฟล์ที่มีคำขอ หลังจากนั้น หน้าต่างที่มีข้อมูลเกี่ยวกับคำขอจะปรากฏขึ้น:

หลังจากตรวจสอบคำขอและตรวจสอบให้แน่ใจว่าได้กรอกอย่างถูกต้องแล้ว คุณสามารถคลิกปุ่ม "นำเข้า" เพื่อป้อนลงในฐานข้อมูล เราทราบทันทีว่าเมื่อคุณพยายามป้อนคำขออีกครั้งในฐานข้อมูล CA จะมีข้อความปรากฏขึ้น:

คำขอในฐานข้อมูลของ CA ถูกทำเครื่องหมาย (คอลัมน์ "ประเภท") ไม่ว่าจะเป็น "Locale" สร้างโดย CA หรือเป็น "Import" ที่สร้างขึ้นโดยผู้สมัครเอง และเวลาที่ได้รับใบสมัครโดย CA คือ บันทึกไว้ด้วย สิ่งนี้มีประโยชน์ในการจัดการกับสถานการณ์ความขัดแย้ง

หากผู้สมัครมาโดยไม่มีใบสมัครและขอให้สร้างก่อนอื่นคุณต้องตัดสินใจ ( การตั้งค่า->ประเภทใบรับรอง->บุคคลธรรมดา->แก้ไข ) ด้วยประเภทคู่คีย์ ( ->คู่คีย์ ), เพื่อจุดประสงค์อะไร ( -> การใช้คีย์ ) ใบรับรองที่ต้องการ:

คู่คีย์สามารถสร้างได้โดยใช้ CIPF "LIRSSL-CSP" (ปุ่ม OpenSSL) และบันทึกไว้ในไฟล์ หรือบนโทเค็น PKCS#11 (ปุ่ม PKCS#11) ในกรณีหลัง คุณต้องระบุไลบรารีสำหรับการเข้าถึงโทเค็นด้วย (เช่น rtpkcs11ecp สำหรับโทเค็น RuToken ECP หรือ ls11cloud สำหรับ )

หลังจากที่คุณตัดสินใจเลือกโปรไฟล์และคลิกปุ่ม "ถัดไป" แล้ว ขั้นตอนเพิ่มเติมไม่ได้แตกต่างจากการออกใบรับรองหลักมากนัก หมายเหตุสำคัญประการหนึ่ง: จำไว้ว่าคุณเก็บคีย์ส่วนตัวและรหัสผ่านไว้ที่ใดเพื่อเข้าถึงคีย์ หากใช้โทเค็น/สมาร์ทการ์ด PKCS#11 เป็น CIPF เพื่อสร้างคู่คีย์ จะต้องเชื่อมต่อกับคอมพิวเตอร์:

แอปพลิเคชันที่สร้างหรือนำเข้าจะอยู่ในฐานข้อมูล CA และแสดงในหน้าต่างหลักบนแท็บ "คำขอใบรับรอง" คำขอที่ได้รับอยู่ภายใต้ "การพิจารณา" (คอลัมน์ "สถานะ" ของแท็บ "คำขอใบรับรอง" และ "คำขอเก็บถาวร") สำหรับแต่ละคำขอที่ได้รับใหม่ ต้องทำการตัดสินใจ (เมนูบริบทเมื่อคุณคลิกขวาที่คำขอที่เลือก):

คำขอแต่ละรายการสามารถปฏิเสธหรืออนุมัติได้:

หากคำขอถูกปฏิเสธ คำขอนั้นจะถูกย้ายจากตารางคำขอปัจจุบันของ reqDB ไปยังตารางการเก็บถาวรคำขอ reqDBArc และด้วยเหตุนี้ จะหายไปจากแท็บคำขอใบรับรองและปรากฏขึ้นอีกครั้งบนแท็บการเก็บถาวรคำขอ

แอปพลิเคชันที่ได้รับอนุมัติจะยังคงอยู่ในตาราง reqDB และบนแท็บ "คำขอใบรับรอง" จนกว่าจะออกใบรับรอง จากนั้นจะเข้าสู่ไฟล์เก็บถาวรด้วย

ขั้นตอนการออกใบรับรอง รายการเมนู "ออกใบรับรอง") แตกต่างจากขั้นตอนการสร้างแอปพลิเคชันเพียงเล็กน้อย:

ใบรับรองที่ออกให้จะปรากฏบนแท็บ "ใบรับรอง" ทันที ในกรณีนี้ ใบรับรองจะเข้าสู่ตาราง certDBNew ของฐานข้อมูล CA และคงอยู่ที่นั่นจนกว่าจะมีการเผยแพร่ ใบรับรองจะถูกเผยแพร่หลังจากส่งออกไปยังดัมพ์ SQL ของใบรับรองใหม่ ซึ่งถูกโอนไปยังบริการสาธารณะ การเผยแพร่ใบรับรองจะย้ายใบรับรองจากตาราง certDBNew ไปยังตาราง certDB

หากคุณกดปุ่มเมาส์ขวาบนบรรทัดที่เลือกในแท็บ "ใบรับรอง" เมนูจะปรากฏขึ้นพร้อมฟังก์ชันต่อไปนี้:

หากคำขอถูกสร้างขึ้นที่ CA ด้วยรหัสที่สร้างและบันทึกไว้ในไฟล์ คุณจะต้องสร้างคอนเทนเนอร์ PKCS # 12 และส่งไปยังผู้สมัคร:

คุณควรใส่ใจกับ "ชื่อที่เป็นมิตร" - คำพูดในนั้นจะต้องหลีกเลี่ยง:

หลังจากสร้างคอนเทนเนอร์ที่ปลอดภัย PKCS#12 แล้ว ไฟล์คีย์ส่วนตัวของผู้สมัครจะถูกทำลาย

ดังนั้น CA จึงเริ่มต้นชีวิตโดยออกใบรับรองฉบับแรก งานหนึ่งของ CA คือการจัดระเบียบการเข้าถึงใบรับรองที่ออกให้ฟรี ตามกฎแล้วการเผยแพร่ใบรับรองจะต้องผ่านบริการเว็บ CAFL63 มีบริการดังกล่าว:

ในการเผยแพร่ใบรับรองและรายการใบรับรองที่ถูกเพิกถอนในบริการสาธารณะ CA จะอัปโหลดใบรับรองไปยังไฟล์ในขั้นต้น (ใบรับรอง->ใบรับรองการส่งออก) หรือทำการดัมพ์ SQL ของตารางใบรับรองทั้งหมด ซึ่งคุณสามารถสร้างฐานข้อมูลใบรับรองได้ และอัปโหลดรายการใบรับรองเข้าไป และจากนั้นทำการดัมพ์ SQL ของใบรับรองใหม่ ซึ่งจะถูกเพิ่มไปยังฐานข้อมูลบริการสาธารณะ:

หน้าที่พื้นฐานของ CA คือการตีพิมพ์รายการใบรับรองที่ถูกเพิกถอน คล้ายกับที่กระทรวงกิจการภายในดำเนินการเกี่ยวกับหนังสือเดินทางที่หมดอายุ ใบรับรองสามารถเพิกถอนได้ตามคำขอของเจ้าของ สาเหตุหลักของการเพิกถอนคือการสูญเสียคีย์ส่วนตัวหรือการสูญเสียความไว้วางใจในคีย์นั้น

หากต้องการเพิกถอนใบรับรอง เพียงเลือกใบรับรองบนแท็บ "ใบรับรอง" คลิกขวาและเลือกรายการเมนู "การเพิกถอนใบรับรอง":

ขั้นตอนการเพิกถอนจะเหมือนกับการสร้างคำขอหรือการออกใบรับรอง ใบรับรองที่ถูกเพิกถอนจะเข้าสู่ตาราง cerDBRev ของฐานข้อมูล CA และปรากฏในแท็บใบรับรองที่ถูกเพิกถอน

ยังคงต้องพิจารณาถึงหน้าที่สุดท้ายของ CA - การเปิดตัว CRL - รายการใบรับรองที่ถูกเพิกถอน รายการ CRL ถูกสร้างขึ้นบนแท็บ "ใบรับรองที่ถูกเพิกถอน" โดยคลิกที่ปุ่ม "สร้าง COS/CRL" สิ่งที่ผู้ดูแลระบบต้องการคือป้อนรหัสผ่านของ CA และยืนยันความตั้งใจที่จะออก CRL:

CRL ที่ออกแล้วจะเข้าสู่ตาราง crlDB ของฐานข้อมูล และแสดงบนแท็บ CRL/COS หากต้องการดู CRL หรือส่งออกเพื่อวัตถุประสงค์ในการเผยแพร่ในบริการสาธารณะ คุณต้องเลือกบรรทัดที่ต้องการเช่นเคย กดปุ่มเมาส์ขวาและเลือกรายการเมนู:

ดาวน์โหลดการแจกจ่าย CAFL63สำหรับแพลตฟอร์ม Win32/Win64, Linux_x86/Linux_x86_64 ยิ่งกว่านั้น ทุกอย่างทำงานสำเร็จบนแพลตฟอร์ม Android

ความสนใจของผู้อ่านได้รับเชิญให้เข้าร่วมงานวิจัย ซึ่งในระหว่างนั้นมีปัญหาหลายประการเกี่ยวกับการใช้เครื่องมือลายเซ็นดิจิทัลที่เกิดขึ้นสำหรับผู้ใช้ Linux โดยเฉพาะอย่างยิ่ง พบจุดที่ไม่ชัดเจนนักต่อไปนี้:

• โอกาสในการได้รับและใช้ใบรับรองลายเซ็นดิจิทัลส่วนบุคคลสำหรับการเข้าถึงบริการสาธารณะในปัจจุบันมีให้โดยองค์กรการค้าเท่านั้นโดยมีค่าธรรมเนียม
• ผู้ให้บริการข้อมูลลายเซ็นอิเล็กทรอนิกส์ที่ออกให้กับผู้ใช้ปลายทางโดยองค์กรที่ได้รับอนุญาตที่แตกต่างกันอาจเข้ากันไม่ได้ทั้งกับพอร์ทัลที่ให้การเข้าถึงบริการรวมถึงบริการสาธารณะ
• ระดับความปลอดภัยของผู้ให้บริการข้อมูลลายเซ็นอิเล็กทรอนิกส์ที่ออกให้กับผู้ใช้อย่างหนาแน่นตามกฎจะลดลงอย่างมากเมื่อเทียบกับระดับเทคโนโลยีที่มีอยู่ในปัจจุบัน
• สำหรับผู้ใช้ OS ส่วนใหญ่จาก Register of Domestic Software กลไก EDS บน Unified Portal of Public Services ไม่สามารถใช้งานได้เนื่องจากความไม่ลงรอยกันของซอฟต์แวร์ EPGU และซอฟต์แวร์ขององค์กรที่ได้รับอนุญาตซึ่งออกใบรับรองลายเซ็นอิเล็กทรอนิกส์ส่วนบุคคล
• ในบางกรณี ผู้พัฒนาพอร์ทัลที่ให้บริการสาธารณะแนะนำให้ใช้ระบบปฏิบัติการที่ไม่รวมอยู่ใน Register เช่นเดียวกับเครื่องมือซอฟต์แวร์และการกำหนดค่าที่ลดความปลอดภัยของข้อมูลผู้ใช้โดยรู้เท่าทัน

ผู้เขียนงานคาดหวังว่าผลลัพธ์ที่ได้จะเป็นประโยชน์กับผู้ใช้โซลูชันที่ใช้กลไก EDS ผู้รวมระบบที่ใช้โซลูชันที่เกี่ยวข้องและจะถูกนำมาพิจารณาโดยองค์กรที่รับผิดชอบในการให้บริการข้อมูลสาธารณะและสำหรับการดำเนินการ กลไกโครงสร้างพื้นฐาน EDS เฉพาะ ตลอดจนนักพัฒนาซอฟต์แวร์และฮาร์ดแวร์ที่เกี่ยวข้อง

มันเกี่ยวกับอะไร

บทความนี้อุทิศให้กับการสนับสนุนลายเซ็นดิจิทัลอิเล็กทรอนิกส์ (EDS) ของเอกสารใน ALT OS รวมถึงข้อมูลเฉพาะของการใช้ EDS ในสหพันธรัฐรัสเซีย

งานหลักคือการทำความเข้าใจว่า "ผู้ใช้ทั่วไป" ™ต้องทำอะไร - ไม่ว่าจะเป็นบุคคลหรือนิติบุคคล - ทำหน้าที่ร่วมกันเพื่อให้สามารถใช้ความสามารถของแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์และพอร์ทัลบริการสาธารณะได้อย่างเต็มที่ในขณะที่ ทำงานใน OS จาก Register of Domestic Software “การใช้งานทั้งหมด” หมายถึง ประการแรก ความเป็นไปได้ของการรับรองความถูกต้องบนไซต์ที่เกี่ยวข้องโดยใช้ใบรับรองที่วางอยู่บนสื่อทางกายภาพที่แยกต่างหาก และความเป็นไปได้ของการลงนามทางอิเล็กทรอนิกส์ของเอกสารที่สร้างขึ้นในส่วนต่อประสานไซต์

มีงานวิจัยจำนวนมากในหัวข้อนี้ซึ่งผลลัพธ์ที่ได้คือข้อสรุปว่าโดยหลักการแล้วทุกอย่างใช้งานได้ สิ่งสำคัญคือต้องเข้าใจที่นี่ว่าการศึกษาส่วนใหญ่เกี่ยวกับความเข้ากันได้กับพอร์ทัลบริการสาธารณะของสหพันธรัฐรัสเซียของเครื่องมือเข้ารหัสที่ทันสมัยที่ทำงานภายใต้ Linux OS นั้นดำเนินการในห้องปฏิบัติการ ตัวอย่างเช่น หากมีข้อตกลงพิเศษระหว่างผู้วิจัยกับหน่วยงานออกใบรับรองที่ออกใบรับรอง น่าเสียดายที่จากผลงานดังกล่าว เป็นการยากที่จะตัดสินความสามารถที่แท้จริงของบุคคลที่กระทำการร่วมกัน

มันทำงานอย่างไร

ในการเข้าสู่ไซต์โดยไม่ต้องเข้าสู่ระบบและรหัสผ่าน แต่เพียงแค่เชื่อมต่อโทเค็นของฮาร์ดแวร์เข้ากับตัวเชื่อมต่อ USB จำเป็นต้องมีซอฟต์แวร์เฉพาะที่สแต็คทำงานอย่างถูกต้องในระบบปฏิบัติการ: รองรับอุปกรณ์ทางกายภาพ, อัลกอริธึมการเข้ารหัส, อินเทอร์เฟซซอฟต์แวร์ , รูปแบบและโปรโตคอลการสื่อสาร ในเวลาเดียวกัน ความเข้ากันได้ของอัลกอริธึมการเข้ารหัส รูปแบบและโปรโตคอลจะต้องได้รับการตรวจสอบนอกขอบเขตความรับผิดชอบของระบบปฏิบัติการ - ในหน่วยงานออกใบรับรองที่ออกใบรับรองและบนไซต์ที่ต้องให้การเข้าถึง

และถ้าเรากำลังพูดถึงเว็บไซต์ของหน่วยงานราชการ ก็มีความจำเป็นที่ cryptocurrencies ที่ใช้นั้นต้องได้รับการรับรองสำหรับการใช้งานที่เหมาะสมใน สหพันธรัฐรัสเซีย.

กลไกพื้นฐาน

เทคโนโลยี EDS ใช้อย่างเป็นทางการในสหพันธรัฐรัสเซีย อิงจากโครงสร้างพื้นฐานของคีย์สาธารณะ ลองดูว่ามันทำงานอย่างไรพร้อมตัวอย่าง

เพื่อความชัดเจน ลองพิจารณากลไกการทำงานของอัลกอริธึมสากลที่เหมาะสมกับทั้งลายเซ็นอิเล็กทรอนิกส์และการเข้ารหัส อัลกอริธึมเหล่านี้รวมถึงมาตรฐานอินเทอร์เน็ต RSA และ Russian GOST R 34.10-94 ซึ่งมีผลบังคับใช้ในสหพันธรัฐรัสเซียในฐานะมาตรฐานลายเซ็นอิเล็กทรอนิกส์จนถึงปี 2544 อัลกอริธึม EDS ที่ทันสมัยกว่าซึ่งรวมถึง GOST R 34.10-2001 ปัจจุบันและ GOST R 34.10-2012 ในปัจจุบันนั้นมีความเชี่ยวชาญเป็นพิเศษ มีไว้สำหรับลงนามในเอกสารเท่านั้น และไม่เหมาะสำหรับการเข้ารหัส ในทางเทคนิค ความแตกต่างระหว่างอัลกอริธึมเฉพาะคือแฮชในกรณีของพวกเขาไม่ได้เข้ารหัส แทนที่จะเข้ารหัส การคำนวณอื่น ๆ จะดำเนินการโดยใช้คีย์ส่วนตัวซึ่งผลลัพธ์จะถูกเก็บไว้เป็นลายเซ็น เมื่อตรวจสอบลายเซ็น การคำนวณเสริมที่เกี่ยวข้องจะดำเนินการโดยใช้กุญแจสาธารณะ การสูญเสียความเป็นสากลในกรณีนี้คือการชำระเงินสำหรับความแข็งแกร่งของการเข้ารหัสที่สูงขึ้น ตัวอย่างด้านล่างที่มีอัลกอริธึมสากลอาจมีความเกี่ยวข้องน้อยกว่าเล็กน้อย แต่อาจเข้าใจได้ง่ายกว่าสำหรับผู้อ่านที่ไม่ได้เตรียมตัวไว้

ลายเซ็นเอกสาร

ดังนั้น ในการสร้างลายเซ็นอิเล็กทรอนิกส์ในโครงสร้างพื้นฐานของคีย์สาธารณะ จึงใช้รูปแบบการเข้ารหัสแบบอสมมาตร ซึ่งมีลักษณะเฉพาะโดยการใช้คีย์คู่ สิ่งที่เข้ารหัสโดยหนึ่งในคีย์เหล่านี้สามารถถอดรหัสได้ด้วยคีย์อื่นของคู่เท่านั้น หนึ่งในกุญแจของทั้งคู่เรียกว่าความลับหรือส่วนตัวและถูกเก็บไว้เป็นความลับที่สุด อีกปุ่มหนึ่งเรียกว่าสาธารณะหรือเปิดและแจกจ่ายอย่างอิสระ - ตามกฎแล้วเป็นส่วนหนึ่งของใบรับรอง นอกจากคีย์แล้ว ใบรับรองลายเซ็นอิเล็กทรอนิกส์ยังรวมถึงข้อมูลเกี่ยวกับเจ้าของใบรับรอง ตลอดจนลายเซ็นของคีย์ พร้อมด้วยข้อมูลเกี่ยวกับเจ้าของที่ทำโดยบุคคลที่เชื่อถือได้ ดังนั้น ใบรับรองจึงมีลายเซ็นอิเล็กทรอนิกส์ที่ยืนยันว่าข้อมูลเกี่ยวกับเจ้าของสอดคล้องกับคู่คีย์แล้ว

ในองค์กร ลายเซ็นนี้ดำเนินการโดยผู้มีอำนาจออกใบรับรอง (CA) ซึ่งเป็นนิติบุคคลที่ได้รับมอบอำนาจให้จัดตั้งและยืนยันการติดต่อของเจ้าของและคีย์ การปฏิบัติตามข้อกำหนดเกิดขึ้นหลังจากการนำเสนอเอกสารที่เป็นกระดาษ และได้รับการยืนยันอย่างแม่นยำด้วยลายเซ็นอิเล็กทรอนิกส์ ซึ่งสะดวกต่อการพิจารณาโดยเพียงแค่ตัวอย่างการทำใบรับรอง

หน่วยงานออกใบรับรองสำหรับการลงนามในใบรับรองไคลเอ็นต์ยังมีคีย์คู่อีกด้วย ข้อมูลที่ยืนยันแล้วเกี่ยวกับเจ้าของใบรับรองในรูปแบบของตารางที่ออกแบบมาเป็นพิเศษจะรวมเป็นเอกสารเดียวพร้อมกุญแจสาธารณะ เอกสารนี้จะผ่านการเปลี่ยนแปลงสองครั้ง ขั้นแรก ฟังก์ชันแฮชจะเปลี่ยนเอกสารเป็นลำดับที่ไม่ซ้ำกันของอักขระที่มีความยาวคงที่ (แฮช) ถัดไป แฮชที่ได้จะถูกเข้ารหัสด้วยไพรเวตคีย์ของผู้ออกใบรับรอง ผลลัพธ์ของการเข้ารหัสคือลายเซ็นอิเล็กทรอนิกส์ที่แท้จริง แนบมากับเอกสารที่ลงนาม ในกรณีนี้ ข้อมูลเกี่ยวกับผู้ใช้และคีย์ของเขา และแจกจ่ายไปพร้อมกับมัน ทั้งหมดนี้ร่วมกัน - เอกสารที่มีข้อมูลเกี่ยวกับผู้ใช้และคีย์สาธารณะของเขาตลอดจนลายเซ็นของเอกสารนี้พร้อมกุญแจสาธารณะของ CA ถูกร่างขึ้นในลักษณะพิเศษและเรียกว่าใบรับรองผู้ใช้

เช่นเดียวกับในกรณีของข้อมูลผู้ใช้ซึ่งเป็นส่วนหนึ่งของใบรับรอง จะมีการออกลายเซ็นอิเล็กทรอนิกส์ของเอกสารอื่น ๆ ตัวอย่างเช่น ไฟล์ที่มีแอปพลิเคชันสำหรับบริการ ไฟล์ถูกแฮช แฮชที่ได้จะถูกเข้ารหัสด้วยรหัสลับของผู้ใช้และแนบไปกับเอกสาร ผลที่ได้คือเอกสารที่ลงนาม

การตรวจสอบลายเซ็น

ตามปกติในกรณีของการเข้ารหัสแบบอสมมาตร สิ่งที่เข้ารหัสด้วยคีย์เดียวสามารถถอดรหัสได้ด้วยคีย์อื่นของคู่เท่านั้น ดังนั้น ในกรณีของใบรับรอง แฮชที่เข้ารหัสของเอกสารที่มีกุญแจสาธารณะของผู้ใช้และข้อมูลที่ตรวจสอบแล้วเกี่ยวกับผู้ใช้นั้นสามารถถอดรหัสได้โดยใช้กุญแจสาธารณะของหน่วยงานออกใบรับรอง ซึ่งแจกจ่ายโดยอิสระโดยเป็นส่วนหนึ่งของใบรับรองของผู้มีอำนาจออกใบรับรอง ดังนั้น ใครก็ตามที่ได้รับใบรับรอง CA จะสามารถรับแฮชที่ถอดรหัสจากใบรับรองผู้ใช้ได้ เนื่องจากฟังก์ชันแฮชสร้างผลลัพธ์ที่ไม่เหมือนใคร โดยนำไปใช้กับเอกสารที่มีคีย์สาธารณะของผู้ใช้และข้อมูลเกี่ยวกับมัน คุณสามารถตรวจสอบว่าแฮชทั้งสองตรงกันหรือไม่ หากเป็นเช่นนั้น เราก็มีเอกสารฉบับเดียวกันกับที่ลงนามโดยศูนย์รับรอง และข้อมูลที่อยู่ในนั้นสามารถเชื่อถือได้ หากไม่ แสดงว่าลายเซ็นไม่ตรงกับเอกสาร และเรามีของปลอม

สถานการณ์ในการตรวจสอบใบรับรอง CA นั้นเหมือนกันทุกประการ - มีการลงนามด้วยคีย์บางตัวด้วย เป็นผลให้สายของใบรับรองที่เซ็นชื่อลงท้ายด้วยใบรับรอง "รูท" ซึ่งลงนามด้วยตนเอง ใบรับรองดังกล่าวเรียกว่าลงนามด้วยตนเอง สำหรับศูนย์รับรองที่ได้รับการรับรองอย่างเป็นทางการของสหพันธรัฐรัสเซีย ใบรับรองหลักคือใบรับรองของ Head Certification Center ของกระทรวงโทรคมนาคมและสื่อสารมวลชน

นอกเหนือจากข้อมูลเกี่ยวกับผู้ใช้และคีย์สาธารณะของเขาแล้ว ใบรับรองยังมีข้อมูลเพิ่มเติม โดยเฉพาะอย่างยิ่ง ระยะเวลาที่มีผลบังคับใช้ของใบรับรอง หากใบรับรองในกลุ่มหมดอายุอย่างน้อยหนึ่งรายการ ลายเซ็นจะถือว่าไม่ถูกต้อง

นอกจากนี้ ลายเซ็นจะถือว่าไม่ถูกต้องหากใบรับรองไคลเอ็นต์ถูกเพิกถอนโดย CA ความสามารถในการเพิกถอนใบรับรองมีประโยชน์ เช่น ในสถานการณ์ที่รหัสลับรั่วไหล ความคล้ายคลึงกับการติดต่อธนาคารในกรณีที่บัตรธนาคารสูญหายนั้นเหมาะสม

บริการของศูนย์ออกใบรับรอง

ดังนั้นศูนย์รับรองที่มีลายเซ็นจะยืนยันการโต้ตอบของคีย์สาธารณะบางชุดกับระเบียนบางชุด ในทางทฤษฎี ค่าใช้จ่ายของ CA สำหรับการลงนามในใบรับรองหนึ่งฉบับนั้นใกล้จะถึงศูนย์: ลายเซ็นนั้นเป็นการดำเนินการทางคอมพิวเตอร์แบบอัตโนมัติที่ดีและไม่แพงมากบนอุปกรณ์ที่ทันสมัย ในเวลาเดียวกัน ค่าบริการของ UC จะได้รับการชำระเงิน แต่ต่างจาก CA ที่ออกใบรับรองสำหรับเว็บไซต์ เงินในที่นี้ไม่ได้ทำมาจากอากาศบริสุทธิ์ทั้งหมด

องค์ประกอบแรกของต้นทุนของใบรับรองคือต้นทุนค่าโสหุ้ยสำหรับการให้บริการ CA ที่ได้รับการรับรอง ซึ่งรวมถึง: ค่าใช้จ่ายของใบรับรอง CA ซึ่งชำระแล้ว ค่าใช้จ่ายของใบอนุญาตสำหรับซอฟต์แวร์ที่ผ่านการรับรอง ค่าใช้จ่ายในการรับรองมาตรการขององค์กรเพื่อปกป้องข้อมูลส่วนบุคคล และอื่นๆ นี่คือวิธีการกำหนดต้นทุน เช่น ใบรับรองส่วนบุคคลของบุคคล ซึ่งทำให้สามารถเซ็นชื่อไฟล์ในเครื่อง เอกสารบนเว็บไซต์บริการสาธารณะและข้อความเมลได้

องค์ประกอบที่สองของต้นทุนของใบรับรองจะปรากฏขึ้นเมื่อผู้ใช้ต้องการใช้ใบรับรองของตน เช่น เพื่อทำงานบนแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์ ตามระเบียบข้อบังคับปัจจุบัน เว็บไซต์ของแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์จะรับรองความถูกต้องของลูกค้าหากตรงตามเงื่อนไขสองข้อ: ประการแรก หากใบรับรองยังไม่หมดอายุ ใบรับรองจะไม่ถูกเพิกถอนและลายเซ็นของใบรับรองนั้นถูกต้อง และประการที่สอง หากใบรับรองระบุชัดเจนว่าได้รับการออกแบบให้ทำงานบนไซต์ใดไซต์หนึ่งโดยเฉพาะ รายการสำหรับสิ่งนี้ดูเหมือนรายการปกติในตารางเดียวกันกับที่เก็บข้อมูลใบรับรองที่เหลือ สำหรับแต่ละรายการดังกล่าวในใบรับรองผู้ใช้แต่ละฉบับ ศูนย์การรับรองจะให้จำนวนหนึ่ง ซึ่งพยายามชดใช้ค่าใช้จ่ายของเจ้าของใบรับรอง ดังนั้นใบรับรองที่อนุญาตให้เข้าสู่แพลตฟอร์มการซื้อขายอิเล็กทรอนิกส์จึงมีราคาแพงกว่า

ภัยคุกคามและการโจมตี

ต่างจากการเข้ารหัส ในกรณีของลายเซ็นอิเล็กทรอนิกส์ งานหลักของผู้โจมตีไม่ใช่เพื่อรับข้อความที่ถอดรหัส แต่เพื่อให้สามารถปลอมแปลงหรือสร้างลายเซ็นอิเล็กทรอนิกส์ของเอกสารโดยพลการ นั่นคือค่อนข้างพูดไม่ใช่เพื่อถอดรหัส แต่เพื่อเข้ารหัส ตามเงื่อนไข - เนื่องจากอัลกอริธึม EDS เฉพาะทางที่ทันสมัยดังที่ได้กล่าวมาแล้วไม่ได้เข้ารหัสแฮชของเอกสาร แต่ดำเนินการทางคณิตศาสตร์ที่มีความหมายคล้ายกัน แต่แตกต่างกันในทางเทคนิค

ตามมาตรฐานที่นำมาใช้ในสหพันธรัฐรัสเซียเมื่อลงนามในเอกสารทางอิเล็กทรอนิกส์อัลกอริธึมการเข้ารหัสจะถูกใช้ที่สอดคล้องกับ มาตรฐานของรัฐ RF (GOST R) ในขณะที่เขียนข้อความนี้ (ครึ่งหลังของปี 2559) เนื่องจากไม่มีอัลกอริธึมใดที่เกี่ยวข้องกับ EDS และมีสถานะเป็นมาตรฐานในสหพันธรัฐรัสเซีย วิธีการโจมตีจึงไม่เป็นที่รู้จักซึ่งมีความซับซ้อนแตกต่างกันอย่างมากจากการแจงนับอย่างง่าย ในทางปฏิบัติ นี่หมายความว่าผู้โจมตีที่มีระดับการเข้าถึงทรัพยากรการคำนวณต่ำกว่าสถานะขนาดใหญ่จะง่ายกว่าที่จะพยายามขโมยคีย์แทนที่จะแฮ็คอัลกอริทึมและปลอมแปลงลายเซ็น

ดังนั้นในกรณีของลายเซ็นอิเล็กทรอนิกส์ เวคเตอร์การโจมตีหลักจึงมุ่งเป้าไปที่การได้รับคีย์ลับจากผู้โจมตี หากคีย์ถูกจัดเก็บไว้ในไฟล์บนดิสก์ คีย์นั้นอาจถูกขโมยได้ทุกเมื่อโดยได้รับสิทธิ์ในการอ่านที่เหมาะสม ตัวอย่างเช่นด้วยความช่วยเหลือของไวรัส หากคีย์ถูกจัดเก็บในรูปแบบที่เข้ารหัส สามารถรับได้ในเวลาที่สมัคร - ตัวอย่างเช่น เมื่อโปรแกรมที่ใช้ลายเซ็นอิเล็กทรอนิกส์ได้ถอดรหัสคีย์แล้วและประมวลผลข้อมูลด้วย ในกรณีนี้ งานจะซับซ้อนมากขึ้น - คุณต้องค้นหาช่องโหว่ในโปรแกรม มิฉะนั้น คุณจะต้องถอดรหัสคีย์ด้วยตนเอง แม้จะมีความยุ่งยากซับซ้อนของงาน แต่ก็ยังค่อนข้างจริง สำหรับผู้เชี่ยวชาญในสาขาที่เกี่ยวข้อง จะจัดอยู่ในหมวดหมู่ของงานประจำ

มีความเป็นไปได้ที่จะทำให้งานในการรับรหัสลับโดยผู้โจมตีมีความซับซ้อนยิ่งขึ้นไปอีก โดยการวางรหัสลับไว้บนสื่อกลางของฮาร์ดแวร์ที่แยกจากกัน ในลักษณะที่กุญแจจะไม่หลุดจากขีดจำกัดของอุปกรณ์ทางกายภาพนี้ ในกรณีนี้ ผู้โจมตีสามารถเข้าถึงคีย์ได้โดยการขโมยอุปกรณ์จริงเท่านั้น การสูญหายของอุปกรณ์จะเป็นสัญญาณให้เจ้าของทราบว่ากุญแจถูกขโมย ในกรณีอื่น ๆ - และนี่คือความแตกต่างที่สำคัญที่สุด - การขโมยกุญแจอาจไม่มีใครสังเกตเห็นและเจ้าของกุญแจจะไม่ทราบทันเวลาว่าจำเป็นต้องติดต่อ CA อย่างเร่งด่วนและเพิกถอนความถูกต้องของใบรับรองของเขา .

ที่นี่อีกครั้ง การเปรียบเทียบกับ บัตรเครดิตธนาคารซึ่งเป็นเครื่องมือตรวจสอบสิทธิ์ในการเข้าถึงบัญชีธนาคาร ขณะที่เธออยู่กับเจ้าของ เขาก็สงบ ถ้าบัตรหายต้องบล็อคทันที ในกรณีนี้ หน้าที่ของผู้โจมตีไม่ใช่การขโมยการ์ด แต่ต้องทำสำเนาอย่างระมัดระวังเพื่อไม่ให้เจ้าของบล็อกการเข้าถึง สำหรับโทเค็นฮาร์ดแวร์สมัยใหม่ วิธีการโคลนยังไม่ทราบในขณะนี้

โทเค็น

ในขณะนี้ คำที่ยอมรับกันโดยทั่วไปสำหรับอุปกรณ์ทางกายภาพแต่ละเครื่องที่ใช้เก็บคีย์ลายเซ็นอิเล็กทรอนิกส์คือโทเค็น โทเค็นสามารถเชื่อมต่อกับคอมพิวเตอร์ผ่าน USB, Bluetooth หรือผ่านอุปกรณ์อ่านพิเศษ โทเค็นที่ทันสมัยส่วนใหญ่ใช้อินเทอร์เฟซ USB แต่ความแตกต่างที่สำคัญระหว่างประเภทของโทเค็นไม่ได้อยู่ในอินเทอร์เฟซการเชื่อมต่อ โทเค็นสามารถแบ่งออกเป็นสองประเภท - โทเค็นที่ใช้จริงเป็นที่เก็บคีย์เท่านั้น และโทเค็นที่ "สามารถ" ดำเนินการเข้ารหัสด้วยตนเองได้

โทเค็นประเภทแรกแตกต่างจากแฟลชไดรฟ์ทั่วไปโดยพื้นฐานแล้วสามารถอ่านข้อมูลได้โดยใช้ซอฟต์แวร์พิเศษเท่านั้น มิเช่นนั้นจะเป็นที่จัดเก็บข้อมูลภายนอกทั่วไป และหากเราเก็บคีย์ลับไว้ ผู้ใดก็ตามที่ได้รับสิทธิ์ในการเข้าถึงอุปกรณ์และรู้วิธีอ่านคีย์จากอุปกรณ์ดังกล่าวก็สามารถขโมยได้ โทเค็นดังกล่าวเรียกว่าโทเค็นซอฟต์แวร์และในทางปฏิบัติไม่ได้ให้ประโยชน์ใด ๆ เมื่อเทียบกับการจัดเก็บคีย์บนดิสก์คอมพิวเตอร์ - เจ้าของคีย์ยังไม่สามารถแน่ใจได้ว่าเขารู้สถานที่ทั้งหมดที่เก็บคีย์ลับของเขาไว้

โทเค็นประเภทที่สองเรียกว่าฮาร์ดแวร์โทเค็น และความแตกต่างที่สำคัญคือรหัสลับไม่สามารถกู้คืนได้ - จะไม่ทิ้งขีดจำกัดของโทเค็น ในการทำเช่นนี้ จะมีการวางชุดซอฟต์แวร์พิเศษไว้บนโทเค็น ซึ่งจะเปิดใช้งานเมื่อโทเค็นเชื่อมต่อกับคอมพิวเตอร์ อันที่จริง โทเค็นดังกล่าวเป็นอุปกรณ์คอมพิวเตอร์อิสระที่มีโปรเซสเซอร์ หน่วยความจำ และแอปพลิเคชันของตัวเองที่สื่อสารกับคอมพิวเตอร์

รหัสลับจะไม่ทิ้งโทเค็นของฮาร์ดแวร์เพราะถูกสร้างขึ้นบนโทเค็นเอง ในการลงนามในเอกสาร แฮชของเอกสารจะถูกโหลดลงในโทเค็น การคำนวณจะทำโดยตรง "บนกระดาน" ของโทเค็นโดยใช้รหัสลับที่เก็บไว้ที่นั่น และลายเซ็นที่เสร็จสิ้นแล้วจะถูกอัปโหลดกลับ ดังนั้น เมื่อทราบตำแหน่งของโทเค็น เราจึงทราบตำแหน่งของรหัสลับเสมอ

หนึ่งในคุณสมบัติหลักของโทเค็นฮาร์ดแวร์คือชุดของอัลกอริธึมการเข้ารหัสที่รองรับ ตัวอย่างเช่น หากเราต้องการใช้โทเค็นฮาร์ดแวร์เพื่อรับรองความถูกต้องบนคอมพิวเตอร์ที่บ้านของเรา โทเค็นสมัยใหม่จะทำอะไรก็ตาม และถ้าเราต้องการรับรองความถูกต้องบนพอร์ทัล State Services เราก็ต้องมีโทเค็นที่รองรับอัลกอริธึมการเข้ารหัสที่ได้รับการรับรองในรัสเซีย

ด้านล่างนี้คือรายการกลไกการเข้ารหัสที่รองรับสำหรับโทเค็น eToken และ JaCarta GOST ในการขอรายการกลไก ยูทิลิตี้เปิด pkcs11-tool ใช้กับพารามิเตอร์ "-M" (จากคำว่า "กลไก") ซึ่งสามารถทำหน้าที่เป็นแอปพลิเคชันไคลเอนต์สำหรับไลบรารีใด ๆ ที่ใช้อินเทอร์เฟซ PKCS # 11 ใน ทิศทาง. libeToken.so และ libjcPKCS11.so.1 ใช้เป็นไลบรารี PKCS#11 สำหรับ eToken และ JaCarta ตามลำดับ ห้องสมุดสำหรับ eToken มีการแจกจ่ายเป็นส่วนหนึ่งของซอฟต์แวร์ SafeNet ห้องสมุดสำหรับ JaCarta สามารถดาวน์โหลดได้จากเว็บไซต์ของ Aladdin R.D.

$ pkcs11-tool --module /usr/local/lib64/libeToken.so.9.1.7 -M กลไกที่รองรับ: DES-MAC, keySize=(8,8), ลงชื่อ, ตรวจสอบ DES-MAC-GENERAL, keySize=( 8,8), ลงนาม, ตรวจสอบ DES3-MAC, keySize=(24,24), ลงนาม, ตรวจสอบ DES3-MAC-GENERAL, keySize=(24,24), ลงชื่อ, ตรวจสอบ AES-MAC, keySize=(16,32) ), เซ็น, ตรวจสอบ AES-MAC-GENERAL, keySize=(16,32), เซ็น, ตรวจสอบ RC4, keySize=(8,2048), เข้ารหัส, ถอดรหัส DES-ECB, keySize=(8,8), เข้ารหัส, ถอดรหัส , ห่อ, แกะ DES-CBC, keySize=(8,8), เข้ารหัส, ถอดรหัส, ตัด, แกะ DES-CBC-PAD, keySize=(8,8), เข้ารหัส, ถอดรหัส, ตัด, แกะ DES3-ECB, keySize= (24,24), hw, เข้ารหัส, ถอดรหัส, ห่อ, แกะ DES3-CBC, keySize=(24,24), hw, เข้ารหัส, ถอดรหัส, ตัด, แกะ DES3-CBC-PAD, keySize=(24,24), hw, เข้ารหัส, ถอดรหัส, ห่อ, แกะ AES-ECB, keySize=(16,32), เข้ารหัส, ถอดรหัส, ตัด, แกะ AES-CBC, keySize=(16,32), เข้ารหัส, ถอดรหัส, ตัด, แกะ AES-CBC -PAD, keySize=(16,32), เข้ารหัส, ถอดรหัส, ตัด, แกะ mechtype-0x1086, keySize=(16,32), เข้ารหัส, ถอดรหัส, ตัด, แกะ mec htype-0x1088, keySize=(16,32), เข้ารหัส, ถอดรหัส, ตัด, แกะ RSA-PKCS-KEY-PAIR-GEN, keySize=(1024,2048), hw, generate_key_pair RSA-PKCS, keySize=(1024,2048 ), hw, เข้ารหัส, ถอดรหัส, ลงชื่อ, sign_recover, ตรวจสอบ, Verify_recover, wrap, แกะ RSA-PKCS-OAEP, keySize=(1024,2048), hw, encrypt, decrypt, wrap, unwrap RSA-PKCS-PSS, keySize= (1024,2048), hw, ลงชื่อ, ตรวจสอบ SHA1-RSA-PKCS-PSS, keySize=(1024,2048), hw, ลงชื่อ, ตรวจสอบ mechtype-0x43, keySize=(1024,2048), hw, ลงชื่อ, ตรวจสอบ mechtype -0x44, keySize=(1024,2048), hw, ลงชื่อ, ตรวจสอบ mechtype-0x45, keySize=(1024,2048), hw, ลงชื่อ, ยืนยัน RSA-X-509, keySize=(1024,2048), hw, เข้ารหัส , ถอดรหัส, ลงชื่อ, sign_recover, ตรวจสอบ, Verify_recover, wrap, unwrap , ตรวจสอบ SHA256-RSA-PKCS, keySize=(1024,2048), hw, ลงชื่อ, ตรวจสอบ SHA384-RSA-PKCS, keySize=(1024,2048), hw , ลงชื่อ, ตรวจสอบ SHA512-RSA-PKCS, keySize=(1024 ,2048), hw, sign, ตรวจสอบ RC4-KEY-GEN, keySize=(8,204 8) สร้าง DES-KEY-GEN, keySize=(8,8), สร้าง DES2-KEY-GEN, keySize=(16,16), สร้าง DES3-KEY-GEN, keySize=(24,24), สร้าง AES -KEY-GEN, keySize=(16,32), สร้าง PBE-SHA1-RC4-128, keySize=(128,128), สร้าง PBE-SHA1-RC4-40, keySize=(40,40), สร้าง PBE-SHA1- DES3-EDE-CBC, keySize=(24,24), สร้าง PBE-SHA1-DES2-EDE-CBC, keySize=(16,16), สร้าง GENERIC-SECRET-KEY-GEN, keySize=(8,2048), hw, สร้าง PBA-SHA1-WITH-SHA1-HMAC, keySize=(160,160), hw, สร้าง PBE-MD5-DES-CBC, keySize=(8,8), สร้าง PKCS5-PBKD2, สร้าง MD5-HMAC-GENERAL, keySize=(8,2048), เซ็น, ตรวจสอบ MD5-HMAC, keySize=(8,2048), เซ็น, ตรวจสอบ SHA-1-HMAC-GENERAL, keySize=(8,2048), เซ็น, ตรวจสอบ SHA-1-HMAC , keySize=(8,2048), เซ็น, ตรวจสอบ mechtype-0x252, keySize=(8,2048), เซ็น, ตรวจสอบ mechtype-0x251, keySize=(8,2048), เซ็น, ตรวจสอบ mechtype-0x262, keySize=(8 ,2048), ลงชื่อ, ตรวจสอบ mechtype-0x261, keySize=(8,2048), ลงชื่อ, ตรวจสอบ mechtype-0x272, keySize=(8,2048), ลงชื่อ, ตรวจสอบ mechtype-0x271, keySize=(8,2) 048) ลงชื่อ ตรวจสอบ MD5, Digest SHA-1, Digest SHA256, Digest SHA384, Digest SHA512, Digest mechtype-0x80006001, keySize=(24,24), สร้าง $ pkcs11-tool --module /usr/local/lib64/ libjcPKCS11.so 1 -M กลไกที่รองรับ: GOSTR3410-KEY-PAIR-GEN, hw, generate_key_pair GOSTR3410, hw, ลงชื่อ, ตรวจสอบ GOSTR3410-WITH-GOSTR3411, hw, ลงชื่อ, ยืนยัน mechtype-0x1204, hw, สืบทอด GOSTR3411, hw, Diges mechtype-0x1220 , สร้าง mechtype-0xC4321101 mechtype-0xC4321102 mechtype-0xC4321103 mechtype-0xC4321104 mechtype-0xC4900001

จะเห็นได้ว่ารายการกลไกที่รองรับสำหรับ eToken นั้นยาวมาก แต่ไม่มีอัลกอริธึม GOST รายการกลไก JaCarta ที่รองรับมีเฉพาะอัลกอริธึม GOST เท่านั้น แต่ในจำนวนที่จำเป็นในการปรับใช้ฟังก์ชัน EDS บนโทเค็นของฮาร์ดแวร์

สิ่งสำคัญคือต้องเข้าใจว่าโทเค็นฮาร์ดแวร์สมัยใหม่โดยทั่วไปสามารถใช้เป็นโทเค็นของซอฟต์แวร์ได้เช่นกัน นั่นคือพวกเขามักจะมีพื้นที่หน่วยความจำขนาดเล็กที่สามารถเข้าถึงได้จากภายนอกซึ่งหากต้องการสามารถใช้เพื่อบันทึกและจัดเก็บคีย์ลับที่สร้างขึ้นภายนอกได้ ในทางเทคโนโลยีมันไม่สมเหตุสมผล แต่จริงๆ แล้ววิธีนี้ใช้กันอย่างแพร่หลาย น่าเสียดายเพราะบ่อยครั้งที่เจ้าของโทเค็นไม่ทราบว่าโทเค็นฮาร์ดแวร์ที่ทันสมัยของเขาซึ่งซื้อมาโดยสุจริตไม่ได้มีค่าธรรมเนียมเล็กน้อยถูกใช้เป็นซอฟต์แวร์

ตัวอย่างของโทเค็นซอฟต์แวร์โดยเฉพาะ ได้แก่ Rutoken S และ Rutoken Lite ตัวอย่างของโทเค็นฮาร์ดแวร์ที่ไม่สนับสนุนอัลกอริธึมการเข้ารหัสที่ได้รับการรับรองในรัสเซีย มีอุปกรณ์ "eToken"; เพื่อรองรับการเข้ารหัสรัสเซีย - "Rutoken EDS", "JaCarta GOST"

ผู้ให้บริการ Crypto

ซอฟต์แวร์ที่ให้โอเปอเรเตอร์สามารถเข้าถึงฟังก์ชั่นการเข้ารหัส - ลายเซ็นอิเล็กทรอนิกส์, การเข้ารหัส, การถอดรหัส, การแฮช - เรียกว่าผู้ให้บริการเข้ารหัส, ผู้ให้บริการฟังก์ชั่นการเข้ารหัส ในกรณีของโทเค็นฮาร์ดแวร์ ผู้ให้บริการเข้ารหัสจะถูกใช้งานโดยตรงบนโทเค็น ในกรณีของโทเค็นซอฟต์แวร์หรือในกรณีของการจัดเก็บคีย์บนดิสก์คอมพิวเตอร์ จะถูกนำไปใช้เป็นแอปพลิเคชันผู้ใช้ทั่วไป

จากมุมมองของการรักษาความปลอดภัยของข้อมูลผู้ใช้ หนึ่งในเวกเตอร์การโจมตีหลักจะถูกส่งไปยังผู้ให้บริการ crypto ซึ่งอยู่ในหน่วยความจำของผู้ให้บริการ crypto ที่รหัสลับถูกถอดรหัส ในกรณีที่โจมตีสำเร็จ ผู้โจมตีจะสามารถแทนที่รหัสแอปพลิเคชันด้วยรหัสของตนเองและทำสำเนาของรหัสลับ แม้ว่าโดยปกติกุญแจจะถูกจัดเก็บในรูปแบบที่เข้ารหัสก็ตาม ดังนั้น ในกรณีของการใช้การเข้ารหัสเพื่อดำเนินการลายเซ็นอิเล็กทรอนิกส์ที่มีผลบังคับทางกฎหมาย รัฐพยายามปกป้องประชาชนจากการรั่วไหลของกุญแจลับที่อาจเกิดขึ้นได้ สิ่งนี้แสดงให้เห็นในความจริงที่ว่าในการทำงานกับลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง จะได้รับอนุญาตอย่างเป็นทางการให้ใช้เฉพาะผู้ให้บริการเข้ารหัสที่มีใบรับรองที่เหมาะสมเท่านั้น และดังนั้นจึงได้ผ่านการตรวจสอบที่เหมาะสมแล้ว

ผู้ให้บริการ Crypto ที่ได้รับการรับรองในสหพันธรัฐรัสเซียสำหรับ EDS ได้แก่ Rutoken EDS, JaCarta GOST, CryptoPro CSP, LISSI-CSP, VipNet CSP สองรายการแรกถูกนำมาใช้โดยตรงบนโทเค็นของฮาร์ดแวร์ ส่วนที่เหลืออยู่ในรูปแบบของแอปพลิเคชันของผู้ใช้ สิ่งสำคัญคือต้องเข้าใจว่าเมื่อซื้อโทเค็นฮาร์ดแวร์ที่ได้รับการรับรองในสหพันธรัฐรัสเซีย เราได้รับผู้ให้บริการเข้ารหัสลับที่ได้รับการรับรองในสหพันธรัฐรัสเซียแล้ว และไม่มีความจำเป็น - ทั้งทางเทคโนโลยีและทางกฎหมาย - ในการซื้อผู้ให้บริการ crypto รายอื่น

นอกเหนือจากชุดของอัลกอริธึมที่รองรับ ผู้ให้บริการเข้ารหัสยังแตกต่างกันในชุดของฟังก์ชันการเข้ารหัส เช่น การเข้ารหัสและถอดรหัสเอกสาร การเซ็นชื่อและการตรวจสอบลายเซ็น การมีอยู่ของอินเทอร์เฟซผู้ใช้แบบกราฟิก และอื่นๆ นอกจากนี้ จากชุดฟังก์ชันทั้งหมดนี้ ผู้ให้บริการเข้ารหัสที่ผ่านการรับรองจะต้องดำเนินการเฉพาะสิ่งที่เกี่ยวข้องโดยตรงกับการใช้งานอัลกอริธึมการเข้ารหัสเท่านั้น อย่างอื่นสามารถทำได้โดยแอปพลิเคชันบุคคลที่สาม นี่เป็นวิธีที่ผู้ให้บริการเข้ารหัสทำงานบนโทเค็นฮาร์ดแวร์: ส่วนต่อประสานผู้ใช้ถูกใช้งานโดยแอปพลิเคชันบุคคลที่สามที่ไม่อยู่ภายใต้การรับรองบังคับ แอปพลิเคชันที่ใช้อินเทอร์เฟซผู้ใช้สื่อสารกับผู้ให้บริการเข้ารหัสบนโทเค็นผ่านอินเทอร์เฟซมาตรฐานอื่น - PKCS#11 ในเวลาเดียวกัน จากมุมมองของผู้ใช้ การทำงานกับคีย์จะเกิดขึ้น ตัวอย่างเช่น โดยตรงจากเบราว์เซอร์ Firefox html อันที่จริง เบราว์เซอร์ผ่านอินเทอร์เฟซ PKCS # 11 ใช้เลเยอร์ซอฟต์แวร์พิเศษที่ใช้กลไกในการเข้าถึงโทเค็นของฮาร์ดแวร์เฉพาะ

นอกจากคำว่า "ผู้ให้บริการเข้ารหัส" แล้ว ยังมีอีกคำหนึ่งที่มีความหมายใกล้เคียงกัน - "วิธีการปกป้องข้อมูลการเข้ารหัส" (CIPF) ไม่มีความแตกต่างที่ชัดเจนระหว่างแนวคิดทั้งสองนี้ เทอมแรกเป็นทางการน้อยกว่า เทอมที่สองมักใช้กับโซลูชันทางเทคนิคที่ผ่านการรับรอง เนื่องจากเอกสารนี้อธิบายถึงเทคโนโลยีเป็นหลักมากกว่าแง่มุมที่เป็นทางการ เราจะใช้คำว่า "cryptoprovider" บ่อยขึ้น

การดำเนินการตามกลไก

อัลกอริธึมลายเซ็นอิเล็กทรอนิกส์

ปัจจุบัน ในสหพันธรัฐรัสเซีย อนุญาตให้ใช้อัลกอริธึมลายเซ็นเพียงสองอัลกอริธึมและอัลกอริธึมการแฮชสองอัลกอริธึมอย่างเป็นทางการสำหรับลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง จนถึงสิ้นปี 2560 อนุญาตให้ใช้ GOST R 34.10-2001 ร่วมกับอัลกอริธึมการแฮช GOST R 34.11-94 ตั้งแต่ต้นปี 2561 อนุญาตให้ใช้เฉพาะ GOST R 34.10-2012 และแฮชตาม GOST R 34.11-2012 ในสถานการณ์ที่ไม่จำเป็นต้องใช้อัลกอริธึม GOST แบบบังคับ คุณสามารถใช้อัลกอริธึมที่มีอยู่ได้

ตัวอย่างเช่น ขณะนี้เว็บไซต์ส่วนใหญ่ที่เข้าถึงได้ผ่านโปรโตคอล HTTP ไม่ทราบวิธีใช้อัลกอริทึม GOST สำหรับการตรวจสอบสิทธิ์ไคลเอ็นต์และเซิร์ฟเวอร์ร่วมกัน ในกรณีที่มีการโต้ตอบกับหนึ่งในไซต์เหล่านี้ ฝั่งไคลเอ็นต์จะต้องใช้อัลกอริธึม "ที่ผลิตจากต่างประเทศ" ด้วย ตัวอย่างเช่น หากคุณต้องการใช้โทเค็นฮาร์ดแวร์เป็นที่เก็บคีย์สำหรับการตรวจสอบสิทธิ์บนเว็บไซต์ State Services คุณจะต้องเลือกโทเค็นที่รองรับ EDS ตาม GOST

ความจำเป็นในการใช้อัลกอริธึมของรัสเซียเมื่อโต้ตอบกับหน่วยงานของรัฐนั้นไม่ได้เกิดขึ้นเลยเนื่องจากความปรารถนาที่จะจำกัดพลเมืองในการเลือกของพวกเขา เหตุผลก็คือรัฐที่ลงทุนในการพัฒนาอัลกอริธึมเหล่านี้มีหน้าที่รับผิดชอบในความแข็งแกร่งของการเข้ารหัสและไม่มีคุณสมบัติที่ไม่ได้ประกาศในนั้น อัลกอริธึมการเข้ารหัสทั้งหมดที่ได้รับมาตรฐานในสหพันธรัฐรัสเซียได้ผ่านการตรวจสอบอย่างอิสระซ้ำแล้วซ้ำเล่าและพิสูจน์คุณค่าของพวกเขาอย่างน่าเชื่อถือ สามารถพูดได้เช่นเดียวกันเกี่ยวกับอัลกอริธึมการเข้ารหัสทั่วไปอื่น ๆ อีกมากมาย แต่น่าเสียดายที่การขาดความสามารถที่ไม่ได้ประกาศในนั้นไม่สามารถพิสูจน์ได้อย่างง่ายดายเช่นเดียวกัน ค่อนข้างชัดเจนว่าจากมุมมองของรัฐ การใช้วิธีการที่ไม่น่าเชื่อถือ เช่น การประมวลผลข้อมูลส่วนบุคคลของพลเมืองนั้นไม่สมเหตุสมผล

อินเทอร์เฟซ รูปแบบ และโปรโตคอล

เพื่อให้มั่นใจถึงความเข้ากันได้เมื่อทำงานกับลายเซ็นอิเล็กทรอนิกส์ มาตรฐานสากลจำนวนหนึ่งได้รับการพัฒนาเกี่ยวกับการจัดเก็บข้อมูลและการจัดหาการเข้าถึง มาตรฐานหลัก ได้แก่ :

• PC/SC - อินเทอร์เฟซระดับต่ำสำหรับการเข้าถึงอุปกรณ์เข้ารหัส รวมถึงโทเค็นของซอฟต์แวร์และฮาร์ดแวร์
• PKCS#11 - อินเทอร์เฟซระดับสูงสำหรับการโต้ตอบกับโมดูลการเข้ารหัสฮาร์ดแวร์ ถือได้ว่าเป็นอินเทอร์เฟซแบบรวมสำหรับการเข้าถึงผู้ให้บริการเข้ารหัส
• PKCS#15 - รูปแบบคอนเทนเนอร์พร้อมคีย์ลายเซ็นอิเล็กทรอนิกส์ มีไว้สำหรับจัดเก็บในอุปกรณ์จริง
• PKCS#12, PEM - รูปแบบคอนเทนเนอร์ที่มีคีย์ลายเซ็นอิเล็กทรอนิกส์สำหรับจัดเก็บในไฟล์ ไบนารี และข้อความ ตามลำดับ
• PKCS#10 - รูปแบบเอกสาร - คำขอลงนามที่ลูกค้าส่งไปยัง CA เพื่อรับใบรับรองที่ลงนาม

สิ่งสำคัญคือต้องเข้าใจว่ามาตรฐานต่างๆ เช่น PKCS#11 หรือ PKCS#15 ได้รับการพัฒนาขึ้นโดยไม่ได้คำนึงถึงลักษณะเฉพาะของสกุลเงินดิจิทัลที่ได้รับการรับรองในสหพันธรัฐรัสเซีย ดังนั้น เพื่อที่จะใช้การสนับสนุนอย่างเต็มที่สำหรับการเข้ารหัสในประเทศ มาตรฐานจะต้องได้รับการสรุปและยังคงต้องได้รับการสรุป กระบวนการในการแก้ไขมาตรฐานนั้นใช้เวลานาน ดังนั้น จนกว่าจะมีการนำมาตรฐานที่สรุปผลไปใช้ในที่สุด การใช้งานของพวกเขาจึงปรากฏว่าไม่เข้ากัน โดยเฉพาะอย่างยิ่ง สิ่งนี้ใช้กับผู้ให้บริการเข้ารหัสลับที่ได้รับการรับรองในสหพันธรัฐรัสเซีย ดังนั้นตอนนี้ผู้ให้บริการ crypto ที่ผ่านการรับรองทั้งหมดมีการใช้งานคอนเทนเนอร์ที่เข้ากันไม่ได้สำหรับการจัดเก็บคีย์บนโทเค็น สำหรับมาตรฐานการแลกเปลี่ยนข้อมูล - PKCS # 10, PKCS # 12, PEM - การใช้งานของพวกเขาโชคดีที่มักจะเข้ากันได้ นอกจากนี้ การตีความมาตรฐาน PC / SC มักจะไม่มีความคลาดเคลื่อน

ประเด็นของการสรุปมาตรฐาน, การพัฒนาข้อเสนอแนะ, การรับรองความเข้ากันได้ในด้าน EDS ในสหพันธรัฐรัสเซียกำลังได้รับการจัดการโดยองค์กรพิเศษ - คณะกรรมการด้านเทคนิคเพื่อการมาตรฐาน "การป้องกันข้อมูลเข้ารหัสลับ" (TK 26) ซึ่งรวมถึงผู้เชี่ยวชาญตัวแทนของ หน่วยงานราชการ ผู้พัฒนา ผู้ให้บริการเข้ารหัสและผู้มีส่วนได้ส่วนเสียอื่น ๆ ใบหน้า อาจมีคนโต้แย้งเกี่ยวกับประสิทธิภาพของงานของคณะกรรมการ แต่การมีอยู่จริงของแพลตฟอร์มดังกล่าวก็มีความสำคัญอย่างยิ่ง

ส่วนซอฟต์แวร์

สแต็คซอฟต์แวร์สำหรับการทำงานกับลายเซ็นอิเล็กทรอนิกส์ประกอบด้วยส่วนประกอบต่อไปนี้:

• การใช้งานอินเทอร์เฟซสำหรับการเข้าถึงคอนเทนเนอร์จัดเก็บข้อมูลระดับต่ำด้วยคีย์ - ตัวอย่างเช่น อินเทอร์เฟซ PC / SC สำหรับการเข้าถึงอุปกรณ์ทางกายภาพ - โทเค็น
• โมดูลที่ใช้อินเทอร์เฟซ PKCS#11 สำหรับการโต้ตอบกับผู้ให้บริการเข้ารหัส - ตัวอย่างเช่น ใช้งานบนโทเค็นของฮาร์ดแวร์
• ผู้ให้บริการเข้ารหัสที่ใช้อัลกอริธึมการเข้ารหัสที่เกี่ยวข้องและดำเนินการกับพวกเขา - ตัวอย่างเช่นลายเซ็นอิเล็กทรอนิกส์หรือการเข้ารหัสข้อมูล
• แอปพลิเคชันผู้ใช้ที่โต้ตอบกับผู้อื่น - ที่เกี่ยวข้องกับผู้ให้บริการเข้ารหัส - เคียงข้างกับโมดูล PKCS # 11 และดำเนินการต่างๆ เช่น ลายเซ็นอิเล็กทรอนิกส์หรือการรับรองความถูกต้องในนามของผู้ใช้

ตัวอย่างสแต็ค:

• แอปพลิเคชันบรรทัดคำสั่ง cryptcp จากซอฟต์แวร์ CryptoPro CSP โต้ตอบกับไลบรารี libcppksc11.so ผ่านอินเทอร์เฟซ PKCS#11 และให้ความสามารถในการลงนามในเอกสารด้วยรหัสลับของผู้ใช้ ในเวลาเดียวกัน ฟังก์ชันของผู้ให้บริการเข้ารหัสจะถูกนำไปใช้อย่างสมบูรณ์ในส่วนประกอบของซอฟต์แวร์ CryptoPro CSP ผู้ให้บริการเข้ารหัสลับของโทเค็นฮาร์ดแวร์ไม่เกี่ยวข้อง

ตัวอย่างอื่น:

• ซอฟต์แวร์เปิด pcsc-lite ใช้อินเทอร์เฟซ PC/SC สำหรับการโต้ตอบกับโทเค็นฮาร์ดแวร์ Rutoken EDS
• ไลบรารี libcppksc11.so จากซอฟต์แวร์ CryptoPro CSP ให้การโต้ตอบกับคอนเทนเนอร์ที่โฮสต์บนโทเค็น ซึ่งเก็บคีย์ส่วนตัวและใบรับรองของผู้ใช้
• แอปพลิเคชั่น "CryptoPro EDS Browser plugin" ซึ่งทำงานเป็นส่วนหนึ่งของเบราว์เซอร์ Firefox html โต้ตอบกับไลบรารี libcppksc11.so ผ่านอินเทอร์เฟซ PKCS # 11 และให้ความสามารถในการเซ็นเอกสารในส่วนต่อประสานเบราว์เซอร์บนเว็บไซต์อิเล็กทรอนิกส์ ชั้นการซื้อขาย; ในเวลาเดียวกัน ฟังก์ชันของผู้ให้บริการเข้ารหัสจะถูกนำไปใช้อย่างสมบูรณ์ในส่วนประกอบของซอฟต์แวร์ CryptoPro CSP ผู้ให้บริการเข้ารหัสลับของโทเค็นฮาร์ดแวร์ไม่เกี่ยวข้อง

ตัวอย่างที่สาม:

• ซอฟต์แวร์เปิด pcsc-lite ใช้อินเทอร์เฟซ PC/SC สำหรับการโต้ตอบกับโทเค็นฮาร์ดแวร์ Rutoken EDS
• ไลบรารี librtpksc11.so ที่ผลิตโดย Aktiv จัดให้มีการโต้ตอบกับผู้ให้บริการเข้ารหัสของโทเค็น
• ผู้ให้บริการเข้ารหัสของโทเค็นทำหน้าที่ลงนามข้อมูลที่ส่งไปยังมันด้วยรหัสลับ รหัสลับไม่ทิ้งขีด จำกัด ของโทเค็น
• แอปพลิเคชั่น Rutoken Plugin ที่ทำงานโดยเป็นส่วนหนึ่งของเบราว์เซอร์ Firefox html โต้ตอบกับไลบรารี librtpksc11.so ผ่านอินเทอร์เฟซ PKCS # 11 และให้ความสามารถในการเซ็นเอกสารในอินเทอร์เฟซของเบราว์เซอร์บนไซต์ที่เข้ากันได้ ในเวลาเดียวกัน ฟังก์ชันของผู้ให้บริการเข้ารหัสจะถูกนำไปใช้อย่างสมบูรณ์บนโทเค็นของฮาร์ดแวร์

ทางเลือกของการใช้งานเฉพาะของสแต็กในปัจจุบันถูกกำหนดโดยปัจจัยสามประการ - ขอบเขตที่ต้องการของ EDS ระดับการรู้หนังสือทางเทคนิคของผู้ใช้และความพร้อมของศูนย์รับรองที่จะทำงานกับคำขอลงนามใบรับรอง .

นอกจากชุดซอฟต์แวร์ฝั่งผู้ใช้ที่ระบุไว้ข้างต้นแล้ว ยังมีอีกสองแอปพลิเคชันที่ต้องพิจารณา อย่างแรกคือซอฟต์แวร์ที่ให้บริการศูนย์รับรอง ประการที่สองคือซอฟต์แวร์ที่เราต้องการใช้งานร่วมกันได้ ตัวอย่างเช่น เว็บไซต์บริการของรัฐ หรือซอฟต์แวร์สำหรับเซ็นเอกสารอิเล็กทรอนิกส์

หากหน่วยงานออกใบรับรองที่เราวางแผนจะรับใบรับรองไม่พร้อมที่จะทำงานกับคำขอลงนามในรูปแบบ PKCS # 10 และสามารถทำงานกับโทเค็นของซอฟต์แวร์เท่านั้น (กล่าวคือ จะรับรู้ว่าโทเค็นใดๆ เป็นซอฟต์แวร์) เราไม่มีทางเลือก ตามกฎแล้ว ในกรณีนี้ ซอฟต์แวร์ CA จะสร้างคู่คีย์สำหรับเรา เขียนถึงโทเค็น สร้างคำขอลายเซ็นทันทีตามคีย์สาธารณะและข้อมูลส่วนบุคคลของเรา ลงนาม และจัดเก็บใบรับรองบนโทเค็น . ใบรับรองและคีย์จะอยู่ในคอนเทนเนอร์รูปแบบปิดที่นักพัฒนาซอฟต์แวร์ CA รู้จักเท่านั้น ดังนั้น ในการเข้าถึงคอนเทนเนอร์ด้วยคีย์ คุณจะต้องซื้อผู้ให้บริการเข้ารหัสจากผู้พัฒนารายเดียวกัน และขอบเขตของ EDS จะถูกจำกัดด้วยความสามารถของซอฟต์แวร์ของผู้พัฒนารายใดรายหนึ่ง ในกรณีนี้ การซื้อโทเค็นของฮาร์ดแวร์นั้นไม่สมเหตุสมผล เพราะคุณสามารถใช้ซอฟต์แวร์ได้ ในกรณีนี้ โทเค็นจะต้องถูกส่งไปยัง CA อย่างแน่นอน

หากหน่วยงานออกใบรับรองที่เราวางแผนจะขอรับใบรับรองพร้อมที่จะทำงานกับคำขอลงนามในรูปแบบ PKCS # 10 ก็ไม่สำคัญสำหรับเราว่าจะใช้ซอฟต์แวร์ประเภทใดใน CA นี้ เราจะสามารถใช้ผู้ให้บริการเข้ารหัสที่เข้ากันได้กับแอปพลิเคชันเป้าหมายของเรา ตัวอย่างเช่น กับแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์หรือเว็บไซต์บริการของรัฐ ในกรณีนี้ คุณไม่จำเป็นต้องพกโทเค็นไปที่ CA เพียงสร้างคำขอลายเซ็นและแสดงที่นั่นพร้อมกับเอกสารที่เป็นกระดาษของคุณ รับใบรับรองและบันทึกไว้ในโทเค็นด้วยตัวคุณเองด้วยความช่วยเหลือจากผู้ให้บริการเข้ารหัสลับที่เลือก

ขออภัย ปัจจุบัน CA เพียงไม่กี่แห่ง (ปลายปี 2559) พร้อมที่จะทำงานกับคำขอลงนาม สถานการณ์นี้ส่วนหนึ่งเกิดจากการขาด ฝึกอบรมทางเทคนิคผู้ใช้ที่ไม่สามารถมั่นใจได้ว่าคำขอลายเซ็นได้รับการดำเนินการอย่างถูกต้อง - ด้วยคุณลักษณะที่จำเป็นทั้งหมดและค่าของพวกเขา คู่มือนี้จัดทำขึ้นเพื่อแก้ปัญหานี้

ฮาร์ดแวร์

ในบรรดาที่นำเสนอบน ตลาดรัสเซียโทเค็นรวมถึงสิ่งต่อไปนี้:

สื่อฮาร์ดแวร์ที่รองรับการเข้ารหัสรัสเซีย: Rutoken EDS, JaСarta GOST, MS_KEY K.

ลองพิจารณาเป็นตัวอย่างรายการกลไกการเข้ารหัสที่รองรับของฮาร์ดแวร์ Rutoken EDS และซอฟต์แวร์ Rutoken_Lite:

$ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M กลไกที่รองรับ: RSA-PKCS-KEY-PAIR-GEN, keySize=(512,2048), hw, generate_key_pair RSA-PKCS, keySize=( 512,2048), hw, เข้ารหัส, ถอดรหัส, ลงชื่อ, ตรวจสอบ RSA-PKCS-OAEP, keySize=(512,2048), hw, เข้ารหัส, ถอดรหัส MD5, Diges SHA-1, Digest GOSTR3410-KEY-PAIR-GEN, hw , generate_key_pair GOSTR3410, hw, ลงชื่อ, ตรวจสอบ mechtype-0x1204, hw, สืบทอด GOSTR3411, hw, Digest GOSTR3410-WITH-GOSTR3411, hw, Digest, ลงนาม mechtype-0x1224, hw, ห่อ, แกะ mechtype-0x1221, เข้ารหัส, hw, เข้ารหัส mechtype-0x1222, hw, เข้ารหัส, ถอดรหัส mechtype-0x1220, hw, สร้าง mechtype-0x1223, hw, ลงชื่อ, ตรวจสอบ $ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M กลไกที่รองรับ:

อย่างที่คุณเห็น รายการกลไกการเข้ารหัสที่รองรับ Rutoken Lite นั้นว่างเปล่า ไม่เหมือนกับ Rutoken EDS ซึ่งรวมถึงอัลกอริทึม GOST และ RSA

โทเค็นของฮาร์ดแวร์ที่ไม่รองรับการเข้ารหัสของรัสเซีย ดังที่ได้กล่าวมาแล้ว รวมถึง JaCarta PKI และ eToken โดยเฉพาะอย่างยิ่ง

ด้วยราคาที่ค่อนข้างต่ำสำหรับโทเค็นฮาร์ดแวร์ที่รองรับการเข้ารหัสของรัสเซีย เราสามารถแนะนำให้ใช้โทเค็นเหล่านี้ได้อย่างมั่นใจ นอกเหนือจากข้อได้เปรียบที่ชัดเจนในรูปแบบของรหัสลับที่ไม่สามารถกู้คืนได้ โทเค็นของฮาร์ดแวร์ยังรวมถึงผู้ให้บริการเข้ารหัสลับที่ผ่านการรับรองด้วย นั่นคือ เป็นไปได้ที่จะจัดระเบียบงานด้วยโทเค็นในลักษณะที่คุณไม่จำเป็นต้องซื้อซอฟต์แวร์ราคาแพงเพิ่มเติม

จากการพัฒนาล่าสุด ฉันต้องการทราบ Rutoken EDS 2.0 พร้อมรองรับมาตรฐาน GOST R 34.10-2012

แอปพลิเคชัน

เครื่องมือผู้ใช้

เปิดเครื่องมือ

ซอฟต์แวร์โอเพ่นซอร์สในปัจจุบันอนุญาตให้คุณใช้ชุดซอฟต์แวร์ที่เกือบสมบูรณ์สำหรับการทำงานกับ EDS

PCSC lite

การใช้งาน PC/SC ที่พัฒนาขึ้นภายในกรอบงานของโครงการ PCSC lite เป็นข้อมูลอ้างอิงสำหรับตระกูล Linux OS โดยรวมอยู่ในชุดซอฟต์แวร์รุ่นต่างๆ ที่พิจารณาในเอกสารนี้สำหรับการทำงานกับ EDS ในอนาคต หากไม่มีการระบุตัวเลือกการใช้งานเฉพาะ เราจะพิจารณาว่าเปิดใช้งานโดยค่าเริ่มต้น

OpenSC

ไลบรารีที่ใช้อินเทอร์เฟซ PKCS#11 ตลอดจนชุดเครื่องมือแอปพลิเคชันที่ใช้ฟังก์ชันการทำงาน ได้รับการพัฒนาโดยเป็นส่วนหนึ่งของโครงการ OpenSC ชุดเครื่องมือนี้รองรับโทเค็นฮาร์ดแวร์จำนวนมาก รวมถึง Rutoken EDS ซึ่งได้รับการสนับสนุนจากผู้เชี่ยวชาญของบริษัท Aktiv ซึ่งพัฒนาโทเค็นของตระกูล Rutoken

การใช้ยูทิลิตี OpenSC ช่วยให้คุณสามารถดำเนินการต่างๆ ต่อไปนี้กับโทเค็นของฮาร์ดแวร์ได้:

• เริ่มต้นโทเค็น - รีเซ็ตการตั้งค่าเป็นสถานะดั้งเดิม
• ตั้งค่า PIN ของผู้ดูแลระบบและผู้ใช้ (หากรองรับ)
• สร้างคู่คีย์ (หากสนับสนุนโดยไลบรารี PKCS#11)
• นำเข้าใบรับรองที่ลงนามโดยผู้มีอำนาจออกใบรับรองไปยังโทเค็น

ไลบรารี PKCS#11 จากแพ็คเกจ OpenSC ช่วยให้คุณสามารถดำเนินการลายเซ็นอิเล็กทรอนิกส์เต็มรูปแบบบนโทเค็นที่รองรับ โทเค็นที่รองรับยังรวมถึง Rutoken EDS

สิ่งสำคัญคือต้องเข้าใจในที่นี้ว่าสำหรับ Rutoken EDS มีตัวเลือกการสนับสนุนซอฟต์แวร์สองแบบที่แตกต่างกันซึ่งเข้ากันไม่ได้ในแง่ของรูปแบบสำหรับการจัดเก็บคีย์บนโทเค็น เมื่อใช้ไลบรารี PKCS # 11 จาก OpenSC เราสามารถใช้สแต็กซอฟต์แวร์แบบเปิดได้ และเมื่อใช้ไลบรารีแบบปิดแบบแจกจ่ายฟรีที่ผลิตโดย Aktiv เราสามารถใช้สแต็ก Aktiva แบบปิดได้

OpenSSL

เพื่อที่จะใช้ความสามารถของ EDS ได้อย่างเต็มที่ นอกเหนือจากไลบรารี PKCS # 11 เองแล้ว แอปพลิเคชันของผู้ใช้จะต้องได้รับการติดตั้งเพื่อให้ผู้ปฏิบัติงานสามารถเข้าถึงฟังก์ชันไลบรารีและความสามารถของโทเค็นได้ ตัวอย่างสำคัญของการใช้งานดังกล่าวคือซอฟต์แวร์โอเพ่นซอร์สจากโครงการ OpenSSL รองรับคุณสมบัติดังต่อไปนี้โดยเฉพาะ:

• การเข้ารหัสข้อมูล
• การถอดรหัสข้อมูล
• ลายเซ็นเอกสาร
• การตรวจสอบลายเซ็น;
• การสร้างคำขอลงนามใบรับรอง
• นำเข้าใบรับรอง;
• การส่งออกใบรับรอง

นอกจากนี้ เมื่อใช้ OpenSSL คุณยังสามารถใช้ฟังก์ชันของหน่วยงานออกใบรับรองที่ครบถ้วน ซึ่งรวมถึง:

• การออกใบรับรองไคลเอ็นต์โดยการลงนามคำขอในรูปแบบ PKCS#10;
• การเพิกถอนใบรับรองไคลเอ็นต์
• การลงทะเบียนใบรับรองที่ออกและเพิกถอน

ข้อบกพร่องเพียงอย่างเดียวของ OpenSSL ในขณะนี้ ซึ่งยังไม่อนุญาตให้มีการติดตั้งซอฟต์แวร์ EDS เวอร์ชันเต็มที่มีคุณลักษณะตามซอฟต์แวร์โอเพ่นซอร์ส คือ การขาดโมดูลเปิดสำหรับการโต้ตอบกับไลบรารี PKCS # 11 พร้อมการสนับสนุน อัลกอริทึม GOST มีการใช้งานโมดูลดังกล่าวแบบปิดซึ่งสร้างโดย Aktiv แต่ไม่รวมอยู่ในการแจกจ่าย OpenSSL พื้นฐาน ดังนั้นด้วยการเปิดตัว OpenSSL เวอร์ชันใหม่ ความเข้ากันได้จึงถูกใช้งานไม่ได้เป็นระยะ การใช้งานโมดูลนี้แบบเปิดยังไม่รองรับอัลกอริทึม GOST

Firefox

นอกจาก OpenSSL แล้ว เบราว์เซอร์ Firefox html ที่มีชื่อเสียงยังสามารถโต้ตอบกับไลบรารี PKCS # 11 ได้อีกด้วย ในการเชื่อมต่อไลบรารี PKCS # 11 คุณต้องไปที่เมนูการจัดการการตั้งค่า "Preferences" จากนั้นเลือก "Advanced" ในรายการแนวตั้งทางด้านซ้ายเลือก "Certificates" ในรายการแนวนอนคลิกปุ่ม "Security Devices" ในกล่องโต้ตอบที่ปรากฏขึ้น ให้คลิกปุ่ม "โหลด" " หน้าต่างอื่นจะปรากฏขึ้นพร้อมตัวเลือกเพื่อเลือกเส้นทางไปยังไฟล์ด้วยไลบรารี PKCS#11 และตัวเลือกในการป้อนชื่อท้องถิ่นสำหรับไลบรารีนั้น คุณสามารถโหลดโมดูล PKCS#11 ได้หลายโมดูลในลักษณะนี้สำหรับอุปกรณ์จริงและอุปกรณ์เสมือนประเภทต่างๆ

ขออภัย ฟังก์ชันการทำงานของ Firefox ยังไม่เพียงพอที่จะลงนามในเอกสารในส่วนต่อประสานเว็บไซต์ ดังนั้น สำหรับสแต็กซอฟต์แวร์ EDS แบบเปิดเต็มรูปแบบพร้อมการรองรับ GOST ยังมีปลั๊กอิน (ปลั๊กอิน) ไม่เพียงพอที่ช่วยให้คุณเข้าถึงวัตถุบนโทเค็นจากซอฟต์แวร์ของไซต์ได้ เราหวังว่าปลั๊กอินดังกล่าวจะถูกเขียนขึ้นในอนาคตอันใกล้นี้ หรือเปิด.

CryptoPro

ในเวอร์ชันของ CryptoPro CSP สูงสุดและรวมถึง 4.0 การจัดการแคชในเครื่องด้วยตนเองจะใช้เพื่อจัดเก็บใบรับรองผู้ใช้และใบรับรอง CA สำหรับงานที่เต็มเปี่ยมด้วยใบรับรองผู้ใช้ จำเป็นที่สำเนาของมันจะต้องอยู่ในแคชในเครื่องหนึ่ง และใบรับรอง CA แบบเต็มสายจนถึงและรวมถึงรูทอันหนึ่ง - ในอีกอันหนึ่ง ในทางเทคโนโลยี คุณลักษณะนี้ของ CryptoPro พูดอย่างเคร่งครัด ไม่ได้มีเหตุผลอย่างสมบูรณ์: เหมาะสมที่จะตรวจสอบลูกโซ่ระหว่างการรับรองความถูกต้อง ความจริงที่แท้จริงของความถูกต้องของใบรับรองไม่ส่งผลต่อความเป็นไปได้ในการลงนาม โดยเฉพาะอย่างยิ่งถ้าเป็นใบรับรองของเราเองและเรารู้ว่ามันมาจากไหน ในขณะที่เขียนเวอร์ชันเบต้าของ CryptoPro CSP นั้นสดใหม่ตามที่นักพัฒนาระบุว่ามีการโหลดห่วงโซ่ใบรับรอง CA โดยอัตโนมัติ แต่การทำให้แน่ใจว่ามีเพียงอันที่ใช้อยู่ในปัจจุบันเท่านั้นที่อยู่ในแคชในเครื่องของใบรับรองผู้ใช้ ดูเหมือนว่าจะยังต้องได้รับการตรวจสอบด้วยตนเอง

นักพัฒนาบุคคลที่สามกำลังพยายามเขียนอินเทอร์เฟซแบบกราฟิกสำหรับ CryptoPro CSP ซึ่งอำนวยความสะดวกในการดำเนินการตามปกติของผู้ใช้ ตัวอย่างของยูทิลิตี้ดังกล่าวคือ rosa-crypto-tool ซึ่งทำการเซ็นชื่อและเข้ารหัสเอกสารโดยอัตโนมัติ แพ็คเกจในการแจกแจง ALT

CryptoPro CA

ซอฟต์แวร์ Lissi SOFT โดดเด่นด้วยการปฏิบัติตามมาตรฐานและข้อกำหนดทางเทคนิคอย่างเข้มงวด ผู้ให้บริการ Crypto รวมถึงผู้ให้บริการที่ไม่ซ้ำใครได้รับการออกแบบให้เป็นไลบรารี PKCS#11 นักพัฒนาระบุว่าเข้ากันได้ดีกับซอฟต์แวร์โอเพ่นซอร์สซึ่งเน้นที่มาตรฐานการสนับสนุนด้วย ตัวอย่างเช่น ด้วยเบราว์เซอร์ html และยูทิลิตี้จากชุด OpenSSL

เกี่ยวกับการจัดการการเข้าถึงไซต์บริการสาธารณะ ผลิตภัณฑ์ Lissy SOFT ก็เป็นที่สนใจเช่นกัน ก่อนอื่น - เข้ากันได้กับ "IFCPlugin" - ปลั๊กอินของเบราว์เซอร์ที่ใช้กลไก EDS บนพอร์ทัล State Services ประการที่สอง ความสามารถของซอฟต์แวร์ผู้ออกใบรับรองเพื่อทำงานกับคำขอลงนามใบรับรองในรูปแบบ PKCS#10

เบราว์เซอร์

บางครั้ง ในการเข้าถึงไซต์ที่เราวางแผนที่จะใช้กลไกลายเซ็นอิเล็กทรอนิกส์ เราต้องใช้เทคโนโลยีอื่นที่ใช้การเข้ารหัสของรัสเซีย ตัวอย่างเช่น สามารถใช้อัลกอริทึม GOST เพื่อจัดระเบียบช่องทางการรับส่งข้อมูลที่เข้ารหัสได้ ในกรณีนี้ จำเป็นต้องมีการรองรับอัลกอริธึมที่เหมาะสมในเบราว์เซอร์ น่าเสียดายที่ Firefox และ Chromium รุ่นอย่างเป็นทางการยังไม่รองรับการเข้ารหัสของรัสเซียอย่างเต็มที่ ดังนั้น คุณต้องใช้แอสเซมบลีอื่น ตัวอย่างเช่น แอสเซมบลีดังกล่าวอยู่ในคลังแสงของสกุลเงินดิจิทัลของบริษัท "CryptoPro" และ "Lissy SOFT" รวมถึงการแจกแจงแบบ Alt

เว็บไซต์

ในบรรดาไซต์ที่ต้องใช้เทคโนโลยีลายเซ็นอิเล็กทรอนิกส์ เราสนใจไซต์ที่ให้บริการสาธารณะเป็นหลัก เช่นเดียวกับแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์ (ETP) น่าเสียดายที่ ETP บางตัวยังไม่รองรับการทำงานกับ OS จาก Register of Russian Software แต่สถานการณ์ค่อยๆ เปลี่ยนไปในทางที่ดีขึ้น

การใช้ EDS สำหรับเว็บไซต์มักจะขึ้นอยู่กับการรับรองความถูกต้องและการลงนามในเอกสารที่สร้างขึ้นในส่วนต่อประสานเว็บไซต์ โดยหลักการแล้ว การรับรองความถูกต้องจะเหมือนกับลายเซ็นของเอกสารอื่นๆ: ไซต์ที่ไคลเอ็นต์ต้องการรับรองความถูกต้องจะสร้างลำดับของอักขระที่ส่งไปยังไคลเอ็นต์ ไคลเอ็นต์ส่งลายเซ็นของลำดับนี้กลับมาโดยใช้คีย์ส่วนตัวและใบรับรอง (ใบรับรองเป็นเวอร์ชันก่อนหน้าเล็กน้อย) ไซต์ใช้กุญแจสาธารณะจากใบรับรองไคลเอ็นต์และยืนยันลายเซ็นของลำดับเดิม เช่นเดียวกับการลงนามในเอกสาร ที่นี่ แทนที่จะเป็นลำดับตามอำเภอใจ เอกสารก็ปรากฏขึ้น

บริการสาธารณะ

จากผลการศึกษา ปรากฏว่า ณ วันที่ 14 ธันวาคม 2016 แพลตฟอร์มการซื้อขายของรัฐบาลกลางส่วนใหญ่ - "", "RTS-tender" และ "Sberbank-AST" พร้อมใช้งานในที่ทำงานที่ใช้ระบบปฏิบัติการ Linux อีกสองไซต์ที่เหลือยังไม่มีความสามารถในการเข้าสู่ระบบด้วยใบรับรองไคลเอ็นต์ นักพัฒนาของพวกเขากำลังวางแผนมาตรการใด ๆ เพื่อให้แน่ใจว่าเข้ากันได้หรือไม่ แต่น่าเสียดายที่ยังไม่ถูกค้นพบ

ในเวลาเดียวกัน ตามคำแนะนำอย่างเป็นทางการของไซต์ทั้งหมด ยกเว้น Unified Electronic Trading Platform ระบบปฏิบัติการ Windows ถูกระบุว่าเป็นระบบปฏิบัติการที่รองรับเพียงระบบเดียว คำตอบอย่างเป็นทางการจากบริการสนับสนุนทางเทคนิคยืนยันข้อมูลนี้ คำแนะนำบนเว็บไซต์ของ United Electronic Trading Platform อธิบายการตั้งค่าเบราว์เซอร์โดยไม่ระบุระบบปฏิบัติการเฉพาะ

ในรูปแบบสรุปผลการศึกษาแสดงไว้ในตาราง:

ตลาดอิเล็กทรอนิกส์	ความสามารถในการเข้าสู่ระบบด้วยใบรับรองผู้ใช้	ความสามารถในการเซ็นเอกสารในอินเทอร์เฟซของแพลตฟอร์ม	เอกสารเกี่ยวกับการทำงานกับไซต์ภายใต้ระบบปฏิบัติการจาก Registry
Sberbank - ระบบการซื้อขายอัตโนมัติ	ใช่	ใช่	ไม่
แพลตฟอร์มการซื้อขายอิเล็กทรอนิกส์แบบครบวงจร	ใช่	ใช่	ใช่

สำหรับ ETP ที่เข้ากันได้กับ Linux เครื่องมือเข้ารหัสที่รองรับเพียงอย่างเดียวในขณะนี้คือปลั๊กอิน Cades ซึ่งใช้ได้เฉพาะ CryptoPro CSP เป็นผู้ให้บริการเข้ารหัส ดังนั้น ข่าวดีก็คือการรับโทเค็นเพื่อเข้าถึงแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์เป็นเรื่องง่ายมาก - CA ส่วนใหญ่ออกให้ ข่าวร้าย - โทเค็นจะใช้ซอฟต์แวร์และจะเข้ากันไม่ได้กับเว็บไซต์บริการของรัฐ

สำหรับแพลตฟอร์มการซื้อขายอื่นๆ วิธีเดียวที่จะเข้าถึงฟังก์ชัน EDS คือส่วนประกอบระบบปฏิบัติการ Windows ที่เรียกว่า CAPICOM ผู้เชี่ยวชาญของ Etersoft ดำเนินการวิจัย ซึ่งเป็นผลมาจากความเป็นไปได้ทางทฤษฎีของการเปิดตัว CAPICOM ในสภาพแวดล้อมของไวน์

เว็บไซต์อื่นๆ

นอกเหนือจากไซต์ที่ระบุไว้ซึ่งใช้ EDS โดยตรง - เพื่อเข้าสู่ไซต์และลงนามในเอกสารที่สร้างขึ้นในอินเทอร์เฟซของไซต์ มีไซต์จำนวนหนึ่งที่ให้ความสามารถในการดาวน์โหลดเอกสารที่ลงนามก่อนหน้านี้ด้วยลายเซ็นอิเล็กทรอนิกส์ที่ผ่านการรับรอง ตัวอย่างคือที่ตั้งของศูนย์ความถี่วิทยุหลัก การเข้าถึงไซต์ดำเนินการโดยการเข้าสู่ระบบและรหัสผ่าน และเอกสารต่างๆ ได้รับการจัดเตรียมและลงนามล่วงหน้า - ในส่วนต่อประสานผู้ใช้ระบบปฏิบัติการ ดังนั้น ในการทำงานกับไซต์ดังกล่าว จำเป็นต้องมีฟังก์ชันของการลงนามในเอกสารในเครื่องเท่านั้น นั่นคือไม่มีข้อจำกัดในการเลือกผู้ให้บริการ crypto ในกรณีนี้

ตัวอย่างโซลูชันแบบเบ็ดเสร็จ

ขออภัย ในขณะนี้ ผู้เขียนเอกสารนี้ไม่ทราบวิธีใช้โทเค็นเดียวกันพร้อมกันบนเว็บไซต์ State Services และบนแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์ ดังนั้น คุณจะต้องสร้างโทเค็นสองรายการด้วยคู่คีย์สองคู่และใบรับรองสองรายการตามลำดับ ไม่ได้เป็นสิ่งต้องห้ามตามกฎหมาย ในทางเทคนิคแล้ว เป็นไปได้ ในด้านการเงิน มันก็ค่อนข้างสมจริงเช่นกัน: โทเค็นหนึ่งจะเป็นเช่นฮาร์ดแวร์ Rutoken EDS อีกอันจะเป็นโมเดล eToken แบบเก่าซึ่งขณะนี้สามารถพบได้โดยมีค่าธรรมเนียมเล็กน้อย

เข้าสู่เว็บไซต์บริการของรัฐ

ในการเข้าถึงบริการของรัฐ ใช้ Rutoken EDS และทำตามขั้นตอนต่อไปนี้:

1. ดาวน์โหลดซอฟต์แวร์ปลั๊กอิน Rutoken จากหน้าเว็บที่ลิงก์
2. ติดตั้งปลั๊กอิน Rutoken - คัดลอกไฟล์ปลั๊กอิน (npCryptoPlugin.so และ librtpkcs11ecp.so) ไปที่ ~/.mozilla/plugins/ ;
3. ไปที่ไซต์ด้วยซอฟต์แวร์ศูนย์การลงทะเบียนและทำตามคำแนะนำเพื่อดำเนินการดังต่อไปนี้ - เริ่มต้นโทเค็น สร้างคู่คีย์ สร้างและบันทึกไฟล์ในเครื่องพร้อมขอลายเซ็นในรูปแบบ PKCS # 10
4. เราจะติดต่อ CA ซึ่งพร้อมที่จะออกใบรับรองเมื่อเราขอลายเซ็น เราจะได้รับใบรับรองในรูปแบบของไฟล์
5. ในอินเทอร์เฟซ "ศูนย์การลงทะเบียน" ให้บันทึกใบรับรองจากไฟล์ที่ได้รับบนโทเค็น
6. ดาวน์โหลดแพ็คเกจรูปแบบ "deb" จากลิงค์ - ไฟล์ IFCPlugin-x86_64.deb ;
7. ใช้ซอฟต์แวร์ "Midnight Commander" (คำสั่ง mc ) "go" ลงในไฟล์แพ็คเกจในไดเร็กทอรี
8. คัดลอกเนื้อหาของไดเรกทอรี สารบัญ/usr/lib/mozilla/pluginsไปยังไดเร็กทอรี ~/.mozilla/plugins ในเครื่อง;
9. ในเบราว์เซอร์ Firefox บนเว็บไซต์ของบริการของรัฐ เราจะทำตามลิงก์ "เข้าสู่ระบบ" และ "เข้าสู่ระบบโดยใช้วิธีการทางอิเล็กทรอนิกส์" ตามลำดับ

ปัญหาหลักในการดำเนินการตามคำสั่งนี้คือการค้นหาผู้มีอำนาจรับรองที่พร้อมที่จะทำงานกับคำขอลายเซ็น

เข้าถึงแพลตฟอร์มการซื้อขายอิเล็กทรอนิกส์

ในการเข้าถึงเว็บไซต์ของแพลตฟอร์มการซื้อขายอิเล็กทรอนิกส์ที่รองรับการทำงานใน Linux ให้ทำตามขั้นตอนต่อไปนี้:

1. สำหรับโทเค็นใดๆ ที่จำหน่ายอย่างเป็นทางการในสหพันธรัฐรัสเซีย เราจะติดต่อศูนย์รับรองใดๆ โดยใช้ CryptoPro CA และเราจะได้รับใบรับรองผู้ใช้และรหัสลับที่จัดเก็บไว้ในโทเค็นในคอนเทนเนอร์รูปแบบที่รองรับโดยซอฟต์แวร์ CryptoPro
2. ตาม คำแนะนำติดตั้งซอฟต์แวร์ "CryptoPro CSP" และ "Cades plugin" สำหรับเบราว์เซอร์ Chromium
3. โดยใช้เบราว์เซอร์ Chromium เราจะไปที่ไซต์ของแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์และเริ่มทำงานกับพวกเขาตามคำแนะนำอย่างเป็นทางการ

ความสามารถในการลงนามในเอกสารในรูปแบบของไฟล์จะมีให้ผ่านยูทิลิตี้คอนโซล CryptoPro และผ่านแอพพลิเคชั่น wrapper ของบริษัทอื่นเช่นเครื่องมือ rosa-crypto-tool ที่กล่าวถึงแล้ว