วิกิพีเดีย

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=11287019"