เทคโนโลยี Device-Bound Session Credentials (DBSC) ใหม่ของ Google สัญญาว่าจะยุติการโจมตีแบบ session hijacking โดยการผูกเซสชันของผู้ใช้เข้ากับฮาร์ดแวร์เฉพาะ แม้ว่าประโยชน์ด้านความปลอดภัยจะชัดเจน แต่ชุมชนเทคโนโลยีกำลังตั้งคำถามอย่างจริงจังเกี่ยวกับความเป็นส่วนตัว การควบคุมของผู้ใช้ และศักยภาพในการสร้างอุปสรรคดิจิทัลใหม่
นวัตกรรมด้านความปลอดภัยหรือกลไกการควบคุม?
DBSC ทำงานโดยการสร้างคู่กุญแจเข้ารหัสลับที่ไม่ซ้ำกันสำหรับแต่ละเซสชัน โดยเก็บไว้อย่างปลอดภัยใน Trusted Platform Module (TPM) ของอุปกรณ์ สิ่งนี้ทำให้คุกกี้เซสชันที่ถูกขโมยไปไม่สามารถใช้งานได้บนอุปกรณ์อื่น ซึ่งแก้ปัญหาที่รบกวนความปลอดภัยเว็บมาหลายทศวรรษได้อย่างมีประสิทธิภาพ เทคโนโลยีนี้ตอบสนองต่อการเพิ่มขึ้นของมัลแวร์ที่ขโมยคุกกี้ ซึ่งกลายเป็นเรื่องธรรมดามากขึ้นเมื่ออาชญากรหันไปใช้วิธีอื่นแทนการโจมตีรหัสผ่าน เนื่องจากการใช้งานการยืนยันตัวตนสองขั้นตอนแพร่หลาย
อย่างไรก็ตาม การอภิปรายในชุมชนเผยให้เห็นความสงสัยอย่างลึกซึ้งเกี่ยวกับแรงจูงใจของ Google ผู้ใช้หลายคนมองว่านี่เป็นส่วนหนึ่งของกลยุทธ์ที่กว้างขึ้นในการควบคุมการเข้าถึงอินเทอร์เน็ตและกำจัดไคลเอนต์ทางเลือกหรือส่วนขยายเบราว์เซอร์ ความกังวลนี้เกิดจากความพยายามก่อนหน้านี้ของ Google ในการใช้งาน Web Environment Integrity ซึ่งจะให้อำนาจเว็บไซต์ในการตรวจสอบความถูกต้องของเบราว์เซอร์และระบบปฏิบัติการของผู้ใช้
TPM (Trusted Platform Module): ชิปพิเศษที่ให้ฟังก์ชันความปลอดภัยที่ใช้ฮาร์ดแวร์ รวมถึงการจัดเก็บกุญแจเข้ารหัสลับอย่างปลอดภัย
ประโยชน์ด้านความปลอดภัยที่สำคัญ:
- ป้องกันการโจมตีแบบ session hijacking จากมัลแวร์ที่ขโมยคุกกี้
- ทำให้โทเค็นเซสชันที่ถูกขโมยไปไม่สามารถใช้งานได้บนอุปกรณ์อื่น
- แก้ไขช่องโหว่ที่ยังคงมีอยู่แม้จะใช้การเข้ารหัส HTTPS แล้ว
- ให้การป้องกันที่เหนือกว่าแฟล็กความปลอดภัยของคุกกี้แบบดั้งเดิม (Secure, HttpOnly, SameSite)
- สามารถขจัดช่องทางหลบเลี่ยงหลักของการยืนยันตัวตนแบบสองขั้นตอน
ทางลาดลื่นสู่การเป็นผู้เฝ้าประตูดิจิทัล
นักวิจารณ์กังวลว่า DBSC เป็นขั้นตอนแรกสู่อินเทอร์เน็ตที่มีข้อจำกัดมากขึ้น ความกลัวคือ Google จะค่อยๆ ทำให้การใช้บริการของพวกเขาโดยไม่มีอุปกรณ์ที่รองรับ TPM ยากขึ้น และในที่สุดจะต้องใช้การรับรองฮาร์ดแวร์สำหรับการเข้าถึงแพลตฟอร์มหลัก สิ่งนี้อาจล็อคผู้ใช้ที่ใช้ระบบปฏิบัติการทางเลือก ฮาร์ดแวร์เก่า หรือการกำหนดค่าที่เน้นความเป็นส่วนตัวออกไปได้อย่างมีประสิทธิภาพ
ความกังวลที่เป็นที่พูดถึงอย่างมากเรื่องหนึ่งเน้นไปที่ผลกระทบต่อเครื่องมือของบุคคลที่สามและระบบอัตโนมัติ บริการที่ถูกต้องตามกฎหมายหลายแห่งพึ่งพาการแบ่งปันคุกกี้เซสชันเพื่อให้คุณค่าแก่ผู้ใช้ เช่น ตัวดึงข้อมูล LinkedIn หรือเครื่องมือจัดการโซเชียลมีเดีย DBSC อาจทำให้บริการเหล่านี้เสียหายโดยสิ้นเชิง บังคับให้ผู้ใช้ใช้แอปอย่างเป็นทางการและจำกัดทางเลือกของพวกเขา
ชุมชนยังชี้ไปที่ระบบ remote attestation ที่มีอยู่ของ Android เป็นหลักฐานของสิ่งที่เทคโนโลยีนี้อาจนำไปสู่ ผู้ใช้ของการแจกจ่าย Android ที่เน้นความเป็นส่วนตัวอย่าง GrapheneOS เผชิญกับข้อจำกัดแล้วเมื่อพยายามเข้าถึงแอปหรือบริการบางอย่าง ซึ่งแสดงให้เห็นว่าการรับรองฮาร์ดแวร์สามารถใช้เพื่อแยกการกำหนดค่าที่ไม่ใช่กระแสหลักออกไปได้อย่างไร
Remote Attestation: กระบวนการความปลอดภัยที่อุปกรณ์พิสูจน์ตัวตนและความสมบูรณ์ต่อเซิร์ฟเวอร์ระยะไกล มักใช้เพื่อตรวจสอบว่าซอฟต์แวร์ไม่ได้ถูกดัดแปลง
ความกังวลของชุมชน:
- ศักยภาพในการสร้างอุปสรรคทางดิจิทัลและการแยกแพลตฟอร์มทางเลือกออกไป
- ความเสี่ยงในการทำลายเครื่องมือของบุคคลที่สามและบริการระบบอัตโนมัติ
- การเปรียบเทียบกับข้อจำกัดของระบบ remote attestation ของ Android
- ความกังวลเกี่ยวกับการขยายตัวแบบค่อยเป็นค่อยไปเพื่อกำหนดให้ต้องมี hardware attestation
- ความกลัวต่อการลดลงของการควบคุมของผู้ใช้และตัวเลือกเบราว์เซอร์
ข้อจำกัดทางเทคนิคและทางเลือก
จากมุมมองทางเทคนิค DBSC เผชิญกับความท้าทายหลายประการ เทคโนโลยีนี้ทำงานได้เฉพาะบนอุปกรณ์ที่มีชิป TPM ซึ่งมีอยู่ในการติดตั้ง Windows ประมาณ 60% ตามข้อมูลของ Google ผู้ใช้ที่ไม่มีฮาร์ดแวร์ที่เข้ากันได้จะไม่ได้รับประโยชน์จากความปลอดภัยเพิ่มเติม ทำให้เกิดระบบสองชั้น
สมาชิกชุมชนบางคนโต้แย้งว่าโซลูชันที่มีอยู่สามารถแก้ไขความปลอดภัยเซสชันได้โดยไม่ต้องใช้ฮาร์ดแวร์พิเศษ การยืนยันตัวตนแบบ SSH key ที่ใช้โดยแพลตฟอร์มอย่าง GitHub แล้ว ให้ประโยชน์ด้านความปลอดภัยที่คล้ายกันโดยไม่ต้องผสานรวม TPM สิ่งนี้ทำให้เกิดความหงุดหงิดในหมู่นักพัฒนาที่มอง DBSC เป็นโซลูชันที่ซับซ้อนโดยไม่จำเป็นสำหรับปัญหาที่เทคโนโลยีที่ง่ายกว่าสามารถแก้ไขได้
ข้อกำหนดรวมถึงการป้องกันความเป็นส่วนตัวบางอย่าง เช่น การป้องกันไม่ให้เว็บไซต์เข้าถึงห่วงโซ่ใบรับรอง TPM ที่อาจเปิดใช้งานการสร้างลายนิ้วมืออุปกรณ์ อย่างไรก็ตาม นักวิจารณ์ยังคงสงสัยว่าการป้องกันเหล่านี้จะยังคงอยู่เมื่อเทคโนโลยีพัฒนาไป
ข้อกำหนดทางเทคนิคของ DBSC :
- ต้องใช้ Trusted Platform Module (TPM) สำหรับการจัดเก็บคีย์อย่างปลอดภัย
- มีให้ใช้งานในการติดตั้ง Windows Chrome ประมาณ 60%
- ใช้การเข้ารหัสแบบกุญแจสาธารณะพร้อมคู่คีย์เฉพาะเซสชัน
- ปัจจุบันอยู่ในช่วงเบต้าสำหรับผู้ใช้ Google Workspace บน Windows Chrome
- ออกแบบมาเพื่อทำงานร่วมกับคุกกี้แบบดั้งเดิม ไม่ใช่เพื่อทดแทน
ผลกระทบต่ออุตสาหกรรมและผลกระทบในอนาคต
ผลกระทบที่กว้างขึ้นของ DBSC ขยายไปเกินความกังวลด้านความเป็นส่วนตัวของแต่ละบุคคล หากได้รับการยอมรับอย่างกว้างขวาง เทคโนโลยีนี้อาจเปลี่ยนแปลงวิธีที่เราโต้ตอบกับเว็บอย่างพื้นฐาน อาจสร้างอุปสรรคใหม่สำหรับนวัตกรรมและการแข่งขัน นักพัฒนารายเล็กและแพลตฟอร์มทางเลือกอาจพบว่าตนเองไม่สามารถแข่งขันกับบริการที่ต้องใช้โครงสร้างพื้นฐานการรับรองฮาร์ดแวร์ที่มีราคาแพง
เวลาของการเปิดตัวนี้ ซึ่งเกิดขึ้นพร้อมกับความคาดหวังการบังคับใช้กฎหมายต่อต้านการผูกขาดที่ลดลง ไม่ได้หลุดจากสายตาของชุมชน หลายคนมองว่านี่เป็นการที่ Google ใช้ประโยชน์จากสภาพแวดล้อมการกำกับดูแลที่อาจอนุญาตให้มีการปฏิบัติต่อต้านการแข่งขันมากขึ้น
แม้จะมีความขัดแย้ง ผู้ใช้บางคนยอมรับประโยชน์ด้านความปลอดภัยที่แท้จริงที่ DBSC สามารถให้ได้ การ session hijacking ยังคงเป็นปัญหาร้ายแรง และโซลูชันที่ใช้ฮาร์ดแวร์ให้การป้องกันที่แข็งแกร่งกว่าแนวทางที่ใช้ซอฟต์แวร์เพียงอย่างเดียว ความท้าทายอยู่ที่การใช้งานการปรับปรุงความปลอดภัยเหล่านี้โดยไม่เสียสละเสรีภาพและทางเลือกของผู้ใช้
เมื่อ DBSC เคลื่อนจากฟีเจอร์ทดลองไปสู่การใช้งานที่กว้างขึ้น ชุมชนเทคโนโลยีจะติดตามอย่างใกล้ชิดเพื่อดูว่าการใช้งานของ Google จะเป็นไปตามสัญญาด้านความเป็นส่วนตัวหรือกลายเป็นเครื่องมืออื่นสำหรับการควบคุมดิจิทัล ผลลัพธ์อาจสร้างแบบอย่างที่สำคัญสำหรับวิธีที่ความปลอดภัยและความเป็นอิสระของผู้ใช้สมดุลกันในอินเทอร์เน็ตสมัยใหม่
อ้างอิง: Google Debuts Device-Bound Session Credentials Against Session Hijacking