ข้ามไปเนื้อหา

X.509

จากวิกิพีเดีย สารานุกรมเสรี

ในการเข้ารหัสข้อมูล X.509 เป็นรูปแบบมาตรฐาน ITU-T สำหรับโครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) และโครงสร้างพื้นฐานการจัดการสิทธิ์ (PMI) ซึ่ง X.509 จะระบุหลากหลายหมวดหมู่ รูปแบบมาตรฐานสำหรับใบรับรองกุญแจสาธารณะ รายการเพิกถอนใบรับรอง ใบรับรอง attribute และขั้นตอนการตรวจสอบเส้นทางการรับรอง

ประวัติและการใช้ประโยชน์

[แก้]

X.509 ถูกออกมาใช้ในวันที่ 3 กรกฎาคม พ.ศ. 2531 และมีความเกี่ยวข้องกับมาตรฐาน X.500 ซึ่งก็ถือว่าเป็นระบบลำดับชั้นที่เข้มงวดของผู้มีอำนาจในการออกใบรับรอง (CAs) ในการออกใบรับรอง ซึ่งแตกต่างจากเว็บรูปแบบของความไว้วางใจเว็บ (Web of trust model) ยกตัวอย่างเช่น PGP ที่ทุกคน (ที่ไม่ใช่เพียงแค่ CAs) ซึ่งอาจจะลงนามและเป็นเครื่องยืนยันถึงความถูกต้องของใบรับรองของผู้อื่น รุ่นที่ 3 ของ X.509 จะรวมไปทั้งความยืดหยุ่นของโครงสร้างอื่นๆ เช่น bridge และ mesh เป็นต้น มันสามารถนำใช้แบบ Peer-to-Peer แต่แทบจะไม่เคยถูกใช้ ระบบ X.500 ถูก implement โดยประเทศอธิปไตย เพื่อบอกข้อมูลประจำตัวร่วมกันเพื่อบรรลุสนธิสัญญาร่วมกัน และ โครงสร้างพื้นฐานกุญแจสาธารณะของ IETF (X.509) หรือ PKIX คณะทำงานได้ทำการปรับมาตรฐานให้กับองค์กรที่มีความยืดหยุ่นมากขึ้นของอินเทอร์เน็ต ในความเป็นจริงใบรับรอง X.509 มักจะหมายถึง IETF ของใบรับรอง PKIX และข้อมูลส่วนตัว CRL ของมาตรฐานใบรับรอง X.509 version 3 ตามที่ระบุไว้ใน RFC 5280 ปกติจะเรียกว่า PKIX สำหรับระบบโครงสร้างพื้นฐานกุญแจสาธารณะ

ใบรับรอง

[แก้]

ในระบบ X.509 ผู้มีอำนาจออกใบรับรองจะออกใบรับรองที่เกี่ยวพันกับกุญแจสาธารณะที่มีชื่อแตกต่างกันในรูปแบบ X.500 หรือชื่ออื่นๆ เช่น e-mail หรือ DNS

ใบรับรองหลักที่น่าเชื่อถือขององค์กรสามารถแจกจ่ายไปยังให้กับพนักงานทุกคนเพื่อให้พวกเขาสามารถระบบ PKI ขององค์กร เบราว์เซอร์ เช่น Internet Explorer Firefox Opera Safari และ Chrome มาพร้อมกับชุดที่กำหนดไว้ของใบรับรองหลัก ดังนั้นใบรับรอง SSL จากผู้ขายรายใหญ่จะทำงานทันที ซึ่งมีผลกับนักพัฒนาเบราว์เซอร์ตรวจสอบ CAs ที่ได้รับความเชื่อถือบุคคลที่ 3 สำหรับเบราว์เซอร์ผู้ใช้

X.509 ยังรวมไปถึงการ implememt มาตรฐานสำหรับรายการเพิกถอนใบรับรอง (CRL) ซึ่งมักจะเพิกเฉยระบบโครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) วิธีรับรอง IETF ในการตรวจสอบความถูกต้องของใบรับรองเป็นโพรโทคอลสถานะของใบรับรองออนไลน์ (OCSP) Firefox 3 ให้ OCSP ตรวจสอบโดยค่าเริ่มต้นของ Windows แต่ละรุ่น รวมไปถึง Vista และอื่นๆต่อมา

โครงสร้างของใบรับรอง

[แก้]

โครงสร้างเล็งเห็นตามมาตรฐานจะถูกแสดงในภาษาที่เป็นทางการคือบทคัดย่อไวยากรณ์

โครงสร้างของใบรับรองดิจิทัล X.509 v3 จะเป็นดังนี้

  • ใบรับรอง
    • รุ่นของใบรับรอง
    • หมายเลขลำดับ
    • Algorithm ID
    • ผู้ออกใบรับรอง
    • ความถูกต้อง
      • Not Before
      • Not After
    • หัวข้อ
    • หัวข้อข้อมูลกุญแจสาธารณะ
      • Algorithm กุญแจสาธารณะ
      • หัวข้อกุญแจสาธารณะ
    • ผู้ออกตัวเอกลักษณ์ (ถ้ามี)
    • หัวข้อตัวเอกลักษณ์ (ถ้ามี)
    • ส่วนขยาย (ถ้ามี)
      • ...
  • Algorithm ลายเซ็นใบรับรอง
  • ลายเซ็นใบรับรอง

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

โครงสร้างของรุ่นที่ 1 ถูกระบุใน RFC 1422

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

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

ในทุกเวอร์ชัน หมายเลขจะต้องไม่ซ้ำกันสำหรับแต่ละใบรับรองที่ออกโดย CA เฉพาะ (ตามที่กล่าวไว้ใน RFC 2459)

ส่วนต่อขยายที่แจ้งการใช้งานที่เฉพาะเจาะจงของใบรับรอง

[แก้]

RFC 5280 (และก่อนหน้า) กำหนดจำนวนของส่วนต่อขยายของใบรับรองที่ระบุวิธีการรับรองจากที่ควรจะใช่ ส่วนใหญ่เป็นส่วนหนึ่งของ joint-iso-ccitt(2) ds(5) id-ce(29) และ OID บางส่วนพบมากที่สุด ระบุไว้ในข้อ 4.2.1 คือ:

  • ข้อจำกัดพื้นฐาน { id-ce 19 } จะใช้ในการระบุใบรับรองว่าเป็นของ CA
  • การใช้คีย์ {id-CE 15} ให้บิตแมปที่ระบุการดำเนินการเข้ารหัสลับซึ่งอาจดำเนินการโดยใช้กุญแจสาธารณะที่มีอยู่ในใบรับรอง ยกตัวอย่างเช่น มันอาจแสดงให้เห็นว่ากุญแจควรใช้ในการรองชื่อรับรอง แต่ไม่ได้ใช้เข้ารหัส
  • การใช้คีย์ขยาย {id-CE 37} จะถูกใช้ในใบรับรองทั่วไปเพื่อระบุวัตถุประสงค์ของกุญแจสาธารณะที่มีอยู่ในใบรับรอง มันมีรายชื่อของ OIDs แต่ละแห่งซึ่งบ่งบอกการใช้งานที่ได้รับอนุญาต ตัวอย่างเช่น {id-PKIX 3 1} แสดงให้เห็นว่า กุญแจมักจะถูกใช้บนเซิฟเวอร์ของการเชื่อมต่อ TLS หรือ SSL {id-PKIX 3 4} แสดงให้เห็นว่ากุญแจถูกใช้เพื่อรักษาความปลอดภัยของอีเมล

โดยทั่วไป ถ้าใบรับรองมีส่วนต่อขยายหลายส่วนของข้อจำกัดการใช้งาน ทุกคนต้องมีความพึงพอใจสำหรับการใช้งานที่กำหนดให้ตามความเหมาะสม RFC 5280 ให้ตัวอย่างที่เฉพาะเจาะจงของใบรับรองที่มีทั้ง keyUsage และ extendedKeyUsage ในกรณีนี้ทั้งคู่จะต้องได้รับการประมวลผลและใบรับรองที่สามารถนำมาใช้เฉพาะในกรณีที่ส่วนต่อขยายของทั้งสองมีความเกี่ยวข้องกันในการระบุการใช้งานของใบรับรอง

ชื่อไฟล์ส่วนต่อขยายของใบรับรอง

[แก้]

ชื่อไฟล์ทั่วไปของส่วนต่อขยายใบรับรอง X.509 คือ

  • .pem - (Privacy-enhanced Electronic Mail) ใบรับรองเข้ารหัสแบบ Base64 DER อยู่ระหว่างส่วนหัวและส่วนท้ายของใบรับรอง
  • .cer, .crt, .der - มักอยู่ในรูปแบบ DER binary แต่ใบรับรองที่เข้ารหัสแบบ Base64 เป็นเรื่องปกติ (ดู .pem ด้านบน)
  • .p7b, .p7c - PKCS#7 โครงสร้าง SignedData ที่ไม่มีข้อมูล เพียงใบรับรอง หรือ CRL
  • .p12 - PKCS#12 อาจมีใบรับรอง (สาธารณะ) และกุญแจส่วนตัว (ป้องกันด้วยรหัสผ่าน)
  • .pfx - PFX ต้นแบบของ PKCS#12 (มักจะมีข้อมูลในรูปแบบ PKCS#12 เช่นเดียวกับ PFX ที่สร้างขึ้นใน IIS)

PKCS#7 เป็นมาตรฐานสำหรับการลงนามหรือการเข้ารหัสข้อมูล (เรียกอย่างเป็นทางการ "ห่อ") ตั้งแต่ใบรับรองจำเป็นในการตรวจสอบลงนามข้อมูลก็เป็นไปได้ที่รวมไว้ในโครงสร้าง SignedData ไฟล์ .P7C เป็น degenerated โครงสร้าง SignedData โดยไม่มีข้อมูลใดๆที่จะลงนาม

PKCS#12 วิวัฒนาการมาจากมาตรฐานการแลกเปลี่ยนข้อมูลส่วนบุคคล (PFX) และถูกนำมาใช้ในการแลกเปลี่ยนข้อมูลส่วนตัวและสาธารณะในไฟล์เดียว

Certificate chains and cross-certification

[แก้]

A certificate chain (ดูแนวคิดเทียบเท่าของ "เส้นทางการรับรอง" ที่กำหนดโดย RFC 5280) เป็นรายการของใบรับรอง (โดยปกติจะเริ่มต้นด้วยการรับรองจากนิติบุคคล) ตามด้วยใบรับรอง CA (โดยปกติจะเป็นคนสุดท้ายที่ถูกลงนามด้วยตนเองในใบรับรอง) ที่มีคุณสมบัติดังต่อไปนี้

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

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

คำอธิบายในวรรคก่อนหน้าเป็นมุมมองที่ง่ายในการตรวจสอบกระบวนการเส้นทางในใบรับรองตามที่กำหนดโดย RFC 5280 ซึ่งเกี่ยวกับการตรวจสอบเพิ่มเติม เช่นตรวจสอบความถูกต้องของวันที่ในใบรับรอง เป็นต้น

แม้ว่าใบรับรอง X.509 สามารถมีผู้ออกไดเพียงคนเดียว (ไม่สามารถมีลายเซ็น CA มากกว่า 1 ลายเซ็น) ซึ่งต่างจาก certificate chains สามารถมีอยู่สำหรับใบรับรองเป้าหมายเพราะว่าใบรับมากกว่า 1 ใบสามารถมีกุญแจสาธารณะเหมือนกันได้ นี่คือสิ่งสำคัญสำหรับ cross-certification ระหว่าง PKI ที่แตกต่างกันและการใช้งานอื่นๆ ดังตัวอย่างต่อไปนี้

{{}}===ตัวอย่างที่ 1 Cross-certification ที่ระดับ CA หลัก ระหว่างโครงสร้างกุญแจสาธารณะ===

นอกเหนือจาก "cert2.2 → cert2" ทางออก certificate chain ลำดับ 2 ที่ถูกต้องสำหรับ cert2.2 แล้ว "cert2.2 → cert2.1 → cert1" ซึ่งช่วยให้ cert2.2 (ออกโดย PKI 2) สามารถเชื่อถือได้โดย PKI 1

ตัวอย่างที่ 2 ต่ออายุใบรับรอง CA

[แก้]

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

เนื่องจากทั้ง cert1 และ cert3 มีกุญแจสาธารณะเดียวกัน (เก่า) มี 2 certificate chains ที่ถูกต้องสำหรับ cert5 "cert5 → cert1" and "cert5 → cert3 → cert2" และ analogously สำหรับ cert6 นี่จะช่วยใช้ใบรับรองผู้ใช้เก่า (เช่น cert5) และใบรับรองใหม่ (เช่น cert6) สามารถเชื่อถือได้โดยบุคคลที่มีใบรับรอง root CA ใหม่หรือเก่า เป็นที่ไว้วางใจในช่วงการเปลี่ยนแปลงไปเป็นกุญแจ CA ใหม่

ตัวอย่างใบรับรอง X.509

[แก้]

นี่คือตัวอย่างใบรับรอง X.509 ที่ผ่านการเข้ารหัสของ www.freesoft.org สร้างโดย OpenSSL เป็นใบรับรองขนาก 1kB มันถูกออกโดย Thawte (ตั้งแต่ได้มาโดย VeriSign และในปัจจุบัน Symantec เป็นเจ้าของ) เรื่องของมันประกอบด้วยรายละเอียดส่วนบุคคลจำนวนมากแต่ส่วนที่สำคัญที่สุดมักจะเป็นชื่อทั่วไป (CN) ซึ่งส่วนนี้ต้องเข้ากับโฮสต์ที่ได้รับการรับรอง รวมทั้งเป็นกุญแจสาธารณะ RSA (โมดูลัสและสัญลักษณ์สาธารณะ) ตามด้วยลายเซ็น คำนวณโดยการทำ Hash MD5 ของส่วนแรกในใบรับรองและการลงนาม (ประยุกต์กับกระบวนการการเข้ารหัส) โดยกุญแจส่วนตัว RSA ของ Thawte

ในการตรวจสอบใบรับรอง ใบรับรองต้องการใบรับรองลำดับที่ 2 เข้ากับผู้ออกใบรับรองลำดับที่ 1 (Thawte Server CA) ลำดับแรกใบรับรองตรวจสอบว่าใบรับรองลำดับที่ 2 คือประเภทของ CA นั่นหมายความว่ามันสามารถนำมาใช้ในการออกใบรับรองอื่นๆ โดยจะทำการตรวจสอบค่า attribute ของ CA ในส่วนต่อขยาย X.509 เวอร์ชัน 3 ดังนั้นกุญแจสาธารณะ RSA จากใบรับรอง CA จะถูกใช้ในการถอดรหัสลายเซ็นบนใบรับรองแรกที่ได้รับการ Hash MD5 ซึ่งต้องเข้ากับ Hash MD5 จริงที่ถูกคำนวณในส่วนที่เหลือของใบรับรอง

นี่คือตัวอย่างของใบรับรองที่ลงนามด้วยตัวเอง ในฐานะผู้ออกใบรับรองเช่นกัน ไม่มีวิธีการตรวจสอบใบรับรองยกเว้นตรวจสอบด้วยตัวมันเอง Thawte เป็นหนึ่งใน root certificate authorities ที่ได้รับการยอมรับจาก Microsoft และ Netscape ใบรับรองนี้มาพร้อมกับเว็บเบราว์เซอร์และเป็นที่ถือเชื่อถือได้โดยปริยาย ในตลอดการใช้งานโดยทั่วไปเชื่อถือใบรับรองซึ่งลงนามรับรองได้ (ตามที่มีในข้อจำกัดเบื้องต้นของ X.509 เวอร์ชัน 3) ซึ่งมันต้องเข้ากับกุญแจส่วนตัวที่ต้องดูแลรักษาอย่างใกล้ชิด

ความปลอดภัย

[แก้]

มีการค้นพบปัญหาเกี่ยวกับโครงสร้างกุญแจสาธารณะ (PKI) โดย Bruce Schneier Peter Gutmann และผู้เชี่ยวชาญด้านความปลอดภัยคนอื่นๆ

ความซับซ้อนใบรับรอง

[แก้]

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

มาตรฐาน X.509 ได้รับการออกแบบมาเพื่อรองรับโครงสร้าง X.500 แต่การใช้งานในวันนี้ cases center บริเวณรอบๆเว็บไซต์ คุณสมบัติหลายอย่างมีน้อยและไม่เกี่ยวข้องในทุกวันนี้ ข้อกำหนด X.509 มาจากการเป็นมากกว่าการทำงานและข้อมูลบรรทัดฐานจะถูกกระจายไปทั่วเอกสารจากส่วนมาตรฐานต่างๆ โปรไฟล์หลายคนได้รับการพัฒนาเพื่อแก้ปัญหานี้ แต่แนะนำปัญหาการทำงานร่วมกันและไม่ได้แก้ไขปัญหา

จุดอ่อนสถาปัตยกรรม

[แก้]
  • ใช้ไปรับรองที่ไม่ถูกขึ้นบัญชีดำ (ใช้ CRLs และ OCSP)
  • CRLs เป็นตัวเลือกที่ไม่ดีเพราะว่ามีขนาดใหญ่และรูปแบบกระจายที่ซับซ้อน
  • ความหมายของ OCSP กำกวมและขาดสถานะการถอนทางประวัติศาสตร์
  • การเพิกถอนใบรับรองไม่ถูกกล่าวต่อ
  • รวมปัญหา : การอ้างเอกลักษณ์ (รับรองผู้ตรวจสอบ) การอ้างแอททริบิวต์ และการอ้างสิทธิถูกรวมในที่เดียวกัน ทำให้เกิดความเป็นส่วนตัว การวางแผนนโยบาย และปัญหาการบำรุงรักษา
  • ปัญหาของผู้แทน : CAs ไม่สามารถจำกัดทางเทคนิค CAs ที่อยู่ภายใต้ จากการออกใบรับรองที่อยู่นอกเหนือ namespace และชุด attribute ซึ่ง X.509 ไม่ได้ใช้คุณสมบัตินี้ ดังนี้ CA จำนวนมากอยู่บนอินเทอร์เน็ต และแบ่งชนิด CAs และนโยบายของ CAs เป็นงานที่ยาก คณะผู้แทนของผู้มีอำนาจภายในองค์กรไม่สามารถจัดการได้ทั้งหมด ขณะที่ทำงานร่วมกัน
  • ปัญหาการรวมกัน : Certificate chains ซึ่งเป็นผลมาจากการอยู่ภายใต้ CAs bridge CAs และการลงนามแบบข้ามกันทำให้ถูกต้อง ซับซ้อน และสิ้นเปลืองในแง่ของเวลาการประมวลผล ความหมายการตรวจสอบเส้นทางอาจจะคลุมเครือ ลำดับชั้นที่มีกลุ่มบุคคลที่ 3 ที่เชื่อถือได้ เป็นรูปแบบเฉพาะ มันอาจจะไม่สะดวกเมื่อมีความสัมพันธ์ที่เชื่อถือได้อยู่แล้ว

ปัญหาของเจ้าหน้าที่ใบรับรอง

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

ปัญหาการใช้งาน

[แก้]

ปัญหาการใช้งานเกิดจากข้อบกพร่องในการออกแบบ bugs การตีความที่แตกต่างกันของมาตรฐาน และขาดการทำงานร่วมกันของมาตรฐานที่ต่างกัน ปัญหาคือ

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

ข้อได้เปรียบ

[แก้]
  • ใบรับรอง MD2-based ถูกนำมาใช้เป็นเวลานานและมีความเสี่ยงที่จะถูกโจมตีแบบ preimage ตั้งแต่ใบรับรองลงนามรับรองเอง ผู้โจมตีจะใช้ลายเซ็นและใช้มันเป็นใบรับรองกลาง
  • ในปี 2548 Arjen Lenstra และ Benne de Weger แสดงให้เห็นว่า ใช้ Hash Collision เพื่อจะสร้างใบรับรอง X.509 2 ชุด ที่มีลายเซ็นเหมือนกันและที่แตกต่างกันเฉพาะกุญแจสาธารณะ ทำได้โดย collision attack บน Hash MD5
  • ในปี 2551 Alexander Sotirov และ Marc Stevens นำเสนอ การสื่อสารที่โกลาหลในสภาคองเกรส การโจมตีอนุญาตให้พวกเขาสร้างเจ้าหน้าที่ใบรับรองปลอม ที่ได้รับการยอมรับจากเบราว์เซอร์ทั่วไป โดยการใช้ประโยชน์จากความจริงที่ว่า RapidSSL ยังคงออกใบรับรอง X.509 โดยขึ้นอยู่กับ MD5
  • ใบรับรอง X.509 ที่ขึ้นอยู่กับ SHA-1 ถือว่าปลอดภัยจนถึงล่าสุด ในเดือนเมษายน 2552 ในที่ประชุม Eurocrypt และนักวิจัยชาวออสเตรเลียของมหาวิทยาลัย Macquarie นำเสนอ การค้นหาเส้นทางที่แตกต่างกันอัตโนมัติโดยสำหรับ SHA-1
  • ใบรับรอง EV เป็นความช่วยเหลือที่จำกัด เพราะเบราว์เซอร์ไม่ได้มีนโยบายที่ไม่อนุญาตใบรับรอง EV
  • มีข้อผิดพลาดการดำเนินการกับ X.509 ซึ่งอนุญาต เช่น ปลอมชื่อเรื่องโดยใช้ สตริงสุดท้ายเป็นช่องว่างหรือการโจมตีรหัสในใบรับรอง

มาตรฐานโครงสร้างพื้นฐานกุญแจสาธารณะสำหรับ X.509

[แก้]
  • PKCS7 (การเข้ารหัสลับข้อความไวยากรณ์มาตรฐาน - กุญแจสาธารณะซึ่งพิสูจน์เอกลักษณ์สำหรับลงนาม และ/หรือ เข้ารหัสข้อความของโครงสร้างพื้นฐานกุญแจสาธารณะ)
  • Secure Sockets Layer (SSL) - โพรโทคอลการเข้ารหัสสำหรับการสื่อสารที่ปลอดภัยทางอินเทอร์เน็ต
  • Online Certificate Status Protocol (OCSP) / Certificate Revocation List (CRL) - เหมาะสำหรับตรวจสอบเอกลักษณ์เฉพาะตัว
  • PKCS12 (มาตรฐานการแลกเปลี่ยนข้อมูลไวยากรณ์ส่วนตัว) - ใช้เก็บกุญแจส่วนตัวที่เหมาะสมใบรับรองกุญแจสาธารณะ

เจ้าหน้าที่ใบรับรอง

[แก้]

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

มีหลาย CA เชิงพาณิชย์คิดค่าบริการ สถาบันการศึกษาและหน่วยงานรัฐบาลอาจมี CAs ของตัวและ CAs ฟรี

การทำงานกลุ่มโครงสร้างพื้นฐานกุญแจสาธารณะ (X.509)

[แก้]

การทำงานกลุ่มโครงสร้างพื้นฐานกุญแจสาธารณะ X.509 (PKIX) เป็นกลุ่มทำงานของ the Internet Engineering Task Force (IETF) ทุ่มเทเพื่อสร้าง RFCs และเอกสารมาตรฐานอื่นๆ ในประเด็นที่เกี่ยวกับโครงสร้างพื้นฐานกุญแจสาธารณะของใบรับรอง X.509 PKIX ก่อตั้งในช่วงฤดูใบไม้ร่วงปี 2538 ร่วมสถาบันมาตรฐานและเทคโนโลยีแห่งชาติ คณะทำงานถูกปิดลงในพฤศจิกายน 2556

โพรโทคอลและมาตรฐานที่สนับสนุนใบรับรอง X.509

[แก้]

ดูเพิ่ม

[แก้]

ดูเพิ่ม

[แก้]
  • ITU-T Recommendation X.509 (2005): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, 08/05.
  • C. Adams, S. Farrell, "Internet X.509 Public Key Infrastructure: Certificate Management Protocols", RFC 2510, March 1999
  • Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 3280, April 2002. Obsoleted by RFC 5280, Obsoletes RFC 2459/ updated by RFC 4325, RFC 4630.
  • Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 2459, January 1999. Obsoleted by RFC 3280.
  • Arjen Lenstra, Xiaoyun Wang and Benne de Weger, On the possibility of constructing meaningful hash collisions for public keys, full version, with an appendix on colliding X.509 certificates, 2005 [1] (see also [2]).

แหล่งข้อมูลอื่น

[แก้]
เข้าถึงจาก "https://th.wikipedia.org/w/index.php?title=X.509&oldid=11544180"