ชุดเข้ารหัสคือชุดอัลกอริธึมที่ช่วยรักษาความปลอดภัยของการเชื่อมต่อเครือข่าย โดยทั่วไปชุดเข้ารหัสจะใช้Transport Layer Security (TLS) หรือSecure Socket Layer (SSL) ซึ่งเป็นโปรโตคอลที่เลิกใช้แล้ว ชุดอัลกอริธึมที่ชุดเข้ารหัสโดยทั่วไปประกอบด้วย: อัลกอริธึมการแลกเปลี่ยนคีย์ อัลกอริธึ มการเข้ารหัสแบบกลุ่มและ อัลกอริธึม รหัสยืนยันข้อความ (MAC) ^{[ 1 ]}

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

โดยรวมแล้ว มีชุดการเข้ารหัสที่แตกต่างกันหลายร้อยชุดซึ่งประกอบด้วยการผสมผสานที่แตกต่างกันของอัลกอริธึมเหล่านี้ ชุดการเข้ารหัสบางชุดให้ความปลอดภัยที่ดีกว่าชุดอื่นๆ แต่ด้วยการนำ TLS 1.3 มาใช้ มีเพียง 5 ชุดการเข้ารหัสเท่านั้นที่ได้รับการสนับสนุนและกำหนดอย่างเป็นทางการ^{[ 2 ]}

โครงสร้างและการใช้งานแนวคิดชุดรหัสถูกกำหนดไว้ในเอกสารมาตรฐาน TLS ^{[ 3 ]} TLS 1.2เป็นเวอร์ชัน TLS ที่แพร่หลายที่สุด เวอร์ชันล่าสุดของ TLS (TLS 1.3) มีข้อกำหนดเพิ่มเติมสำหรับชุดรหัส ชุดรหัสที่กำหนดไว้สำหรับ TLS 1.2 ไม่สามารถใช้ใน TLS 1.3 ได้ และในทางกลับกัน เว้นแต่จะระบุไว้เป็นอย่างอื่นในคำจำกัดความ

รายการอ้างอิงของชุดเข้ารหัสที่มีชื่อจะอยู่ในทะเบียนชุดเข้ารหัส TLS ^{[ 4 ]}

การใช้รหัสลับเป็นส่วนหนึ่งของ โปรโตคอลการส่งผ่าน Secure Socket Layer (SSL) มาตั้งแต่เริ่มแรก SSL ได้ถูกแทนที่ด้วย TLS สำหรับการใช้งานส่วนใหญ่ อย่างไรก็ตาม ชื่อCipher Suiteไม่ได้ถูกใช้ในร่างแรกของ SSL แต่ความสามารถที่ไคลเอนต์และเซิร์ฟเวอร์สามารถเลือกจากชุดรหัสลับจำนวนเล็กน้อยเพื่อรักษาความปลอดภัยการเชื่อมต่อของพวกเขานั้นเรียกว่าCipher-Choice ^{[ 5 ] [ 6 ]}จนกระทั่ง SSL v3 (เวอร์ชันสุดท้ายของ SSL) จึงได้มีการใช้ ชื่อ Cipher Suite ^{[ 7 ]}ทุกเวอร์ชันของ TLS ตั้งแต่นั้นมาได้ใช้Cipher Suiteในการกำหนดมาตรฐาน แนวคิดและวัตถุประสงค์ของCipher Suiteไม่ได้เปลี่ยนแปลงไปนับตั้งแต่มีการบัญญัติคำนี้ขึ้นครั้งแรก มันถูกและยังคงถูกใช้เป็นโครงสร้างที่อธิบายอัลกอริทึมที่เครื่องรองรับเพื่อให้เครื่องสองเครื่องสามารถตัดสินใจได้ว่าจะใช้อัลกอริทึมใดในการรักษาความปลอดภัยการเชื่อมต่อ สิ่งที่เปลี่ยนแปลงไปคือเวอร์ชันของอัลกอริทึมที่รองรับใน Cipher Suite TLS แต่ละเวอร์ชันได้เพิ่มการรองรับเวอร์ชันของอัลกอริทึมที่แข็งแกร่งขึ้น และลบการรองรับเวอร์ชันของอัลกอริทึมที่ถูกระบุว่าไม่ปลอดภัย

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

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

ความหมายของชื่อนี้คือ:

ทีแอลเอส

กำหนดโปรโตคอลที่ชุดการเข้ารหัสนี้ใช้ ซึ่งโดยทั่วไปจะเป็น TLS

อีซีดีเอช

ระบุอัลกอริทึมการแลกเปลี่ยนคีย์ที่ใช้

อาร์เอสเอ

กลไกการตรวจสอบสิทธิ์ระหว่างการจับมือ (Handshake)

เอเอส

รหัสลับเซสชัน

128

ขนาดคีย์การเข้ารหัสเซสชัน(บิต) สำหรับการเข้ารหัส

จีซีเอ็ม

ประเภทของการเข้ารหัส (การพึ่งพาบล็อกการเข้ารหัสและตัวเลือกเพิ่มเติม)

ชา

ฟังก์ชันแฮช (SHA2) สำหรับค่าแฮชตั้งแต่ 256 ขึ้นไป กลไกการลงลายมือชื่อ ระบุอัลกอริทึมการตรวจสอบความถูกต้องของข้อความที่ใช้ในการตรวจสอบความถูกต้องของข้อความ

256

ขนาดของไฟล์ข้อมูล (บิต)

ตั้งแต่ TLS 1.3 เป็นต้นไป ชื่อชุดการเข้ารหัสจะไม่รวมประเภทใบรับรอง (RSA) หรือกลไกการแลกเปลี่ยนคีย์ (ECDHE) อีกต่อไป เนื่องจากมีการเจรจาแยกกันในเวอร์ชันใหม่^{[ 8 ] [ 9 ]}

ในการใช้ชุดเข้ารหัส ลูกค้าและเซิร์ฟเวอร์ต้องตกลงกันเกี่ยวกับชุดเข้ารหัสเฉพาะที่จะใช้ในการแลกเปลี่ยนข้อความ ทั้งลูกค้าและเซิร์ฟเวอร์ต้องรองรับชุดเข้ารหัสที่ตกลงกันไว้ หากลูกค้าและเซิร์ฟเวอร์ไม่ตกลงกันเกี่ยวกับชุดเข้ารหัส จะไม่มีการเชื่อมต่อเกิดขึ้น^{[ 10 ]}กระบวนการเลือกนี้เกิดขึ้นระหว่างโปรโตคอลการจับมือ TLS TLS 1.3 มีโปรโตคอลการจับมือ TLS ที่แตกต่างจาก TLS/SSL เวอร์ชันก่อนหน้าและเวอร์ชันปัจจุบัน

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

ในการทดสอบว่าเซิร์ฟเวอร์รองรับการเข้ารหัส TLS ใดบ้าง สามารถใช้ SSL/TLS Scanner ได้[1]

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

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

หาก บิต prefer server cipherของ ข้อความ serverHelloถูกตั้งค่าเป็น true ชุดเข้ารหัสที่เจรจาไว้จะถูกเลือกใช้ในรายการชุดเข้ารหัสของ ข้อความ serverHelloมิเช่นนั้น ชุดเข้ารหัสที่เจรจาไว้จะถูกเลือกใช้ในรายการชุดเข้ารหัสของข้อความclientHello ^{[ 11 ]}

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

หากเครื่องสองเครื่องสื่อสารกันผ่าน TLS 1.3 พวกมันจะประสานงานกันว่าจะใช้ชุดเข้ารหัสใดโดยใช้โปรโตคอลการจับมือ (Handshake Protocol) ของ TLS 1.3 การจับมือใน TLS 1.3 ถูกลดเหลือเพียงรอบเดียวเมื่อเทียบกับสองรอบที่จำเป็นในเวอร์ชันก่อนหน้าของ TLS/SSL

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

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

หาก บิต prefer server cipherของ ข้อความ serverHelloถูกตั้งค่าเป็น true ชุดเข้ารหัสที่เจรจาไว้จะถูกเลือกใช้ในรายการชุดเข้ารหัสของ ข้อความ serverHelloมิเช่นนั้น ชุดเข้ารหัสที่เจรจาไว้จะถูกเลือกใช้ในรายการชุดเข้ารหัสของข้อความclientHello ^{[ 12 ]}

หลังจากที่ไคลเอนต์ได้รับข้อความ เสร็จสิ้นจากเซิร์ฟเวอร์แล้ว ไคลเอนต์จะประสานงานกับเซิร์ฟเวอร์ว่าจะใช้ชุดการเข้ารหัสใด^{[ 13 ]}

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับอัลกอริธึมที่รองรับใน TLS 1.0–1.2 โปรดดูที่: ความปลอดภัยของเลเยอร์การขนส่ง § แอปพลิเคชันและการนำไปใช้

ใน TLS 1.3 อัลกอริทึมแบบเดิมจำนวนมากที่เคยรองรับใน TLS เวอร์ชันแรกๆ ได้ถูกยกเลิกไปเพื่อทำให้โปรโตคอลมีความปลอดภัยมากขึ้น^{[ 15 ]}นอกจากนี้ อัลกอริทึมการเข้ารหัสและการตรวจสอบความถูกต้องทั้งหมดได้ถูกรวมเข้าด้วยกันในอัลกอริทึมการเข้ารหัสแบบตรวจสอบความถูกต้องพร้อมข้อมูลที่เกี่ยวข้อง (AEAD) และต้องใช้อัลกอริทึมแฮชในการสร้างคีย์แบบ HMAC ( HKDF ) ด้วย ^{[ 16 ]}การเข้ารหัสแบบไม่ใช้ AEAD ทั้งหมดได้ถูกลบออกเนื่องจากอาจมีจุดอ่อนหรือช่องโหว่ และการเข้ารหัสจะต้องใช้ อัลกอริทึมการแลกเปลี่ยน คีย์ชั่วคราวเพื่อให้มีการสร้างคู่คีย์ใหม่สำหรับการแลกเปลี่ยนแต่ละครั้ง^{[ 17 ]}

Datagram Transport Layer Security (DTLS) มีพื้นฐานมาจาก TLS แต่ใช้สำหรับ การเชื่อมต่อ UDP โดยเฉพาะ แทนที่จะเป็นการ เชื่อมต่อ TCPเนื่องจาก DTLS มีพื้นฐานมาจาก TLS จึงสามารถใช้ชุดการเข้ารหัสส่วนใหญ่ที่อธิบายไว้สำหรับ TLS ได้ อย่างไรก็ตาม มีกรณีพิเศษที่ต้องพิจารณาเมื่อใช้ชุดการเข้ารหัส TLS กับ DTLS DTLS ไม่รองรับการเข้ารหัสแบบสตรีม RC4 ซึ่งหมายความว่าไม่สามารถใช้ชุดการเข้ารหัส TLS ที่ใช้ RC4 กับ DTLS ได้^{[ 18 ]}

การดูว่าชุดเข้ารหัส TLS เข้ากันได้กับ DTLS หรือไม่โดยการดูชื่อจะไม่ช่วยอะไร ชุดเข้ารหัส TLS แต่ละชุดจะยังคงมีช่องว่างตัวระบุ TLS อยู่ในชื่อ เช่นTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256แต่ปัจจุบันรีจิสทรีพารามิเตอร์ TLS ทั้งหมดจะมีแฟล็กDTLS-OKเพื่อส่งสัญญาณว่าชุดเข้ารหัสรองรับ DTLS หรือไม่^{[ 19 ]}

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

เมื่อเริ่มต้นการจับมือกัน ไคลเอนต์สมัยใหม่จะเสนอโปรโตคอลระดับสูงสุดที่รองรับ หากการเชื่อมต่อล้มเหลว ไคลเอนต์จะลองใหม่โดยอัตโนมัติด้วยโปรโตคอลที่ต่ำกว่า เช่น TLS 1.0 หรือ SSL 3.0 จนกว่าการจับมือกับเซิร์ฟเวอร์จะสำเร็จ จุดประสงค์ของการลดระดับคือเพื่อให้ TLS เวอร์ชันใหม่เข้ากันได้กับเวอร์ชันเก่า อย่างไรก็ตาม เป็นไปได้ที่ผู้โจมตีจะใช้ประโยชน์จากคุณสมบัตินี้และทำให้ไคลเอนต์ลดระดับโดยอัตโนมัติเป็นเวอร์ชันของ TLS หรือ SSL ที่รองรับชุดการเข้ารหัสที่มีอัลกอริทึมที่ทราบกันดีว่ามีความปลอดภัยต่ำและมีช่องโหว่^{[ 20 ]} ซึ่งส่งผลให้เกิดการ โจมตี เช่นPOODLE

วิธีหนึ่งในการหลีกเลี่ยงช่องโหว่ด้านความปลอดภัยนี้คือการปิดใช้งานความสามารถของเซิร์ฟเวอร์หรือไคลเอ็นต์ในการลดระดับเป็น SSL 3.0 ข้อเสียของการแก้ไขนี้คือฮาร์ดแวร์รุ่นเก่าบางอย่างไม่สามารถเข้าถึงได้โดยฮาร์ดแวร์รุ่นใหม่กว่า หากจำเป็นต้องใช้การสนับสนุน SSL 3.0 สำหรับฮาร์ดแวร์รุ่นเก่า จะมีชุดการเข้ารหัส TLS_FALLBACK_SCSV ที่ได้รับการอนุมัติซึ่งตรวจสอบว่าการลดระดับไม่ได้ถูกกระตุ้นด้วยเจตนาร้าย^{[ 21 ]}

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

1. TLS_PSK_WITH_AES_128_CCM_8 ( คีย์ที่ใช้ร่วมกันล่วงหน้า ) ^{[ 22 ]}
2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ( คีย์สาธารณะดิบ )

ชุดการเข้ารหัสแต่ละชุดเหล่านี้ได้รับการนำไปใช้เพื่อทำงานบนอุปกรณ์ที่มีข้อจำกัดด้านกำลังประมวลผลและหน่วยความจำ โดยทั้งสองชุดได้รับการนำไปใช้ในโครงการโอเพนซอร์สTinyDTLSเหตุผลที่พวกมันสามารถทำงานบนอุปกรณ์ที่มีข้อจำกัดเหล่านี้ได้ก็เพราะว่าพวกมันสามารถนำไปใช้ในลักษณะที่มีน้ำหนักเบา การใช้งานชุดการเข้ารหัสคีย์ที่ใช้ร่วมกันล่วงหน้าใช้ RAM เพียง 1889 ไบต์และ ROM แฟลช 38266 ไบต์ ซึ่งประหยัดทรัพยากรมากเมื่อเทียบกับอัลกอริธึมการเข้ารหัสและความปลอดภัยส่วนใหญ่^{[ 23 ]} การใช้หน่วยความจำต่ำนี้เป็นผลมาจากชุดการเข้ารหัสเหล่านี้ใช้อัลกอริธึมที่มีประสิทธิภาพและปลอดภัย แต่อาจจะไม่ปลอดภัยเท่ากับอัลกอริธึมที่ต้องการทรัพยากรมากกว่า เช่น การเข้ารหัส 128 บิตเทียบกับการเข้ารหัส 256 บิต นอกจากนี้ยังใช้คีย์ที่ใช้ร่วมกันล่วงหน้าหรือ คีย์สาธารณะ ดิบซึ่งต้องการพื้นที่หน่วยความจำและกำลังประมวลผลน้อยกว่าเมื่อเทียบกับการใช้โครงสร้างพื้นฐานคีย์สาธารณะ แบบดั้งเดิม (PKIX) ^{[ 24 ]}

ในทางการเขียนโปรแกรม ชุดรหัสลับจะถูกกล่าวถึงทั้งในรูปพหูพจน์และเอกพจน์ ซึ่งแต่ละรูปมีความหมายแตกต่างกัน:

CipherSuite cipher_suites

รายการตัวเลือกการเข้ารหัสที่ไคลเอนต์รองรับ^{[ 25 ]}ตัวอย่างวิธี การใช้ cipher_suitesในระหว่างกระบวนการจับมือ:

struct { ProtocolVersion client_version ; Random random ; SessionID session_id ; CipherSuite cipher_suites < 2 .. 2 ^ 16 - 2 >; CompressionMethod compression_methods < 1 .. 2 ^ 8 - 1 >; select ( extensions_present ) { case false : struct {}; case true : Extension extensions < 0 .. 2 ^ 16 - 1 >; }; } ClientHello ;

CipherSuite cipher_suite

ชุดการเข้ารหัสที่เซิร์ฟเวอร์ เลือก จาก cipher_suitesของไคลเอ็นต์^{[ 26 ]}ตัวอย่างวิธี การใช้ cipher_suiteในระหว่างกระบวนการจับมือ:

struct { ProtocolVersion server_version ; Random random ; SessionID session_id ; CipherSuite cipher_suite ; CompressionMethod compression_method ; select ( extensions_present ) { case false : struct {}; case true : Extension extensions < 0 .. 2 ^ 16 - 1 >; }; } ServerHello ;

• การเข้ารหัสลับ
• ความปลอดภัยของข้อมูล
• โมดูลรักษาความปลอดภัยฮาร์ดแวร์