เราอธิบายบริการระบบคลาวด์ที่ใช้ฮาร์ดแวร์ที่มีความปลอดภัยเพื่อจัดเก็บคีย์การเข้ารหัส เช่น การเข้าถึงการเข้าถึงดังกล่าวได้รับการปกป้องโดยปัจจัยความรู้ที่มีความผันผวนต่ำ (เช่น PIN ของหน้าจอล็อก) ฮาร์ดแวร์ที่มีความปลอดภัยออกแบบมาเพื่อป้องกันการโจมตีด้วยวิธีถอดรหัสโดยทำให้คีย์การเข้ารหัสที่จัดเก็บไว้ไม่สามารถดึงข้อมูลได้ถาวรหลังจากมีการพยายามป้อนปัจจัยที่ทราบที่ถูกต้องไม่สำเร็จหลายครั้งเกินไป
ผู้เขียน: Shabsi Walfish
วันที่ของเวอร์ชัน: 06-03-2018
หมายเหตุ: เอกสารนี้ยังอยู่ระหว่างการปรับปรุง และรายละเอียดการใช้งานยังอยู่ระหว่างการสรุป เมื่อระบบทำงานได้อย่างเสถียรและผลิตเอกสารประกอบได้มากขึ้น เราจะอัปเดตเอกสารประกอบนี้ให้มีรายละเอียดมากขึ้น (โดยเฉพาะเมื่อมีการเผยแพร่โอเพนซอร์สที่เกี่ยวข้อง)
ภาพรวม
โดยทั่วไปแล้ว การเข้ารหัส (ซึ่งใช้เพื่อรักษาความเป็นส่วนตัวของข้อมูล) ต้องใช้ความลับที่มีความสับสนสูงจากมุมมองของผู้โจมตี ต้องใช้ความผันผวนสูงเนื่องจากรูปแบบการเข้ารหัสต้องต้านทานการโจมตีด้วยกำลังดุร้ายซึ่งจะสำรวจพื้นที่ของข้อมูลลับที่เป็นไปได้ทั้งหมดจนกว่าจะพบข้อมูลลับที่ถูกต้อง เมื่อพิจารณาถึงกำลังการประมวลผลที่มีอยู่ในปัจจุบัน ข้อกำหนดขั้นต่ำที่สมเหตุสมผลสำหรับความผันผวนของข้อมูลลับทางวิทยาการเข้ารหัสอาจอยู่ที่ประมาณ 70-80 บิต แต่น่าเสียดายที่มนุษย์จดจำและนึกถึงรหัสผ่านหรือข้อมูลลับอื่นๆ ที่มีเอนโทรปีในระดับนั้น1 ได้ยากมาก โดยเฉพาะหากไม่ค่อยได้ใช้ (แต่การใช้รหัสผ่านที่มีเอนโทรปีสูงบ่อยๆ นั้นเป็นเรื่องยากและน่าเบื่อ) ปัญหาที่ยากลำบากจึงเกิดขึ้นว่าเราจะปกป้องข้อมูลส่วนตัวด้วยเทคโนโลยีการเข้ารหัสได้อย่างไรหากต้องการให้รหัสผ่านเป็น "ปัจจัยความรู้" ที่ผู้ใช้มีแนวโน้มจะจดจำได้ ปัญหานี้แก้ได้ยากมากเนื่องจากเหตุผลหลายประการ บริการพื้นที่เก็บข้อมูลระบบคลาวด์จึงมักจะเข้ารหัสข้อมูลด้วยข้อมูลลับที่จัดการโดยผู้ให้บริการพื้นที่เก็บข้อมูลระบบคลาวด์เอง แทนที่จะให้ผู้ใช้จดจำข้อมูลลับของตนเอง
วิธีหนึ่งในการเชื่อมโยงช่องว่างระหว่างข้อกําหนดสําหรับความลับทางวิทยาการเข้ารหัสและความลับที่มนุษย์จดจําได้คือการใช้บริการ Cloud Key Vault (CKV) เพื่อจัดเก็บ "คีย์การกู้คืน" ที่มีความสับสนสูง ซึ่งได้รับการปกป้องโดยความลับที่มนุษย์จดจําได้ที่มีความสับสนต่ำ บริการ CKV จะปล่อยคีย์การกู้คืนแก่บุคคลที่พิสูจน์ได้ว่าทราบความลับที่มนุษย์จำได้ บริการ CKV สามารถป้องกันการโจมตีด้วยวิธี Brute Force กับข้อมูลลับที่มนุษย์จำได้ ซึ่งจะบังคับใช้ขีดจำกัดที่แน่นอนเกี่ยวกับจำนวนครั้งที่พยายามไม่สำเร็จเพื่อพิสูจน์ความรู้เกี่ยวกับข้อมูลลับ คีย์การกู้คืนเป็นคีย์การเข้ารหัสแบบสมมาตรมาตรฐาน ซึ่งเหมาะสำหรับใช้กับรูปแบบการเข้ารหัส (ที่มีการตรวจสอบสิทธิ์) ที่สามารถเข้ารหัสข้อมูลจำนวนมาก (เช่น การสำรองข้อมูลดิสก์) ได้อย่างง่ายดายและสามารถจัดเก็บไว้ที่ใดก็ได้อย่างปลอดภัย ข้อมูลที่เข้ารหัสดังกล่าวจะไร้ประโยชน์สำหรับทุกคนที่ไม่สามารถรับคีย์การกู้คืน
เอกสารประกอบนี้อธิบายแนวทางการสร้างบริการ Cloud Key Vault โดยใช้โมดูลฮาร์ดแวร์ที่เชื่อถือได้ (THM) การใช้งานบริการ CKV ครั้งแรกของเราออกแบบมาเพื่อปกป้องคีย์การกู้คืนด้วยปัจจัยความรู้ในหน้าจอล็อก (LSKF) ของผู้ใช้ ซึ่งเป็น PIN ลับ รหัสผ่าน หรือรูปแบบการปัดที่ใช้ปลดล็อกสมาร์ทโฟน มนุษย์สามารถจดจำ LSKF ได้อย่างน่าเชื่อถือ ในขณะเดียวกัน โดยทั่วไปแล้วความลับ LSKF ดังกล่าวจะมีจำนวนข้อมูลสุ่มเพียงพอที่จะต่อต้านผู้โจมตีที่มีความพยายามเพียงไม่กี่ครั้ง จึงเหมาะสําหรับบริการ CKV
แอปพลิเคชันแรกที่เราจะนำบริการ Cloud Key Vault ไปใช้คือเปิดใช้การสำรองข้อมูล Android ที่เข้ารหัสฝั่งไคลเอ็นต์ ก่อนหน้านี้ ไฟล์ที่เข้ารหัสในเครื่องบนอุปกรณ์ Android จะใช้คีย์ที่ได้รับการปกป้องด้วย LSKF ของผู้ใช้ แต่ข้อมูลสำรองของไฟล์เหล่านั้นที่จัดเก็บ (และเข้ารหัส) ในระบบคลาวด์จะไม่ได้รับการปกป้องโดย LSKF เป็นครั้งแรกที่ Cloud Key Vault เปิดใช้การป้องกันด้วยหน้าจอล็อกสำหรับข้อมูลสำรอง Android ที่เก็บไว้ในระบบคลาวด์ด้วย ซึ่งหมายความว่าเซิร์ฟเวอร์ของ Google จะไม่สามารถเข้าถึงหรือกู้คืนเนื้อหาของข้อมูลสำรองที่เข้ารหัสได้ มีเพียงอุปกรณ์ที่มี LSKF ของผู้ใช้เท่านั้นที่จะถอดรหัสข้อมูลสำรองได้
แนวคิดหลัก
ในตอนแรก แพลตฟอร์มไคลเอ็นต์ที่รองรับบริการ Cloud Key Vault มีเพียงระบบปฏิบัติการ Android 9 Pie เท่านั้น และเมื่อเราพูดถึงไคลเอ็นต์ตลอดทั้งเอกสารนี้ เราหมายถึงอุปกรณ์ที่ใช้ระบบปฏิบัติการ Android 9 Pie ที่มีบริการ Google Play การติดตั้งใช้งานฝั่งเซิร์ฟเวอร์ของเราทำงานบนเซิร์ฟเวอร์ Google ที่กําหนดไว้เป็นพิเศษซึ่งมีการติดตั้งชิป Titan2 เพิ่มเติม ชิป Titan ที่ออกแบบโดย Google ทำหน้าที่เป็นคอมโพเนนต์ฮาร์ดแวร์ในโมดูลฮาร์ดแวร์ที่เชื่อถือได้ของเรา และเราได้จัดสรรอุปกรณ์นี้เป็นพิเศษด้วยบูตโหลดเดอร์และเฟิร์มแวร์ที่กำหนดเองซึ่งใช้โปรโตคอลและกลไกการบังคับใช้การรักษาความปลอดภัยของเรา (ตามที่อธิบายไว้ที่นี่) เราใช้เทคนิคการรับรองฮาร์ดแวร์เพื่อให้มั่นใจว่าโปรโตคอลของเราทำงานอยู่บนฮาร์ดแวร์ Titan จริงๆ
บริการ CKV ต้องปรับขนาดเพื่อรองรับการเข้าชมจากอุปกรณ์ Android หลายพันล้านเครื่อง3 โดยไม่สูญเสียข้อมูลผู้ใช้จำนวนมากเนื่องจากความล้มเหลวของฮาร์ดแวร์ (เช่น ชิปไหม้) หรือหยุดทำงานเป็นเวลานานเนื่องจากการบำรุงรักษาศูนย์ข้อมูล ด้วยเหตุนี้ เซิร์ฟเวอร์ที่มีชิปไททันจึงจัดเรียงเป็นกลุ่ม โดยแต่ละกลุ่มประกอบด้วย THM อิสระหลายรายการซึ่งมีสำเนาของข้อมูลคีย์เดียวกัน กลุ่มประชากรตามรุ่นหนึ่งๆ จะกระจายอยู่ในศูนย์ข้อมูลที่แยกจากกันทางกายภาพในโซนการบำรุงรักษาที่แตกต่างกัน เพื่อให้ระบบสามารถบรรลุเป้าหมายด้านความพร้อมใช้งานและความน่าเชื่อถือได้ สำหรับการขยายขนาด เราจะแบ่งกลุ่มลูกค้าออกเป็นกลุ่มประชากรตามรุ่นต่างๆ เพื่อให้ปรับความจุของบริการได้โดยการเพิ่มเซิร์ฟเวอร์เพื่อเพิ่มจำนวนกลุ่มประชากรตามรุ่นที่มีอยู่
ตอนนี้เราพร้อมที่จะแจกแจงองค์ประกอบหลักๆ ของสถาปัตยกรรมบริการ Cloud Key Vault แล้ว
คอมโพเนนต์สถาปัตยกรรม / อภิธานศัพท์
ปัจจัยความรู้ของหน้าจอล็อก (LSKF): ข้อมูลลับที่มนุษย์จำได้ เช่น PIN แบบสั้น รูปแบบการปัดบนตารางจุด 3 x 3 หรือรหัสผ่าน ข้อมูลลับนี้ใช้เพื่อปกป้องความสามารถในการปลดล็อกอุปกรณ์ในเครื่อง และถือว่าเป็นปัจจัยการตรวจสอบสิทธิ์หลัก (หรือ "ที่รัดกุม") สำหรับการล็อกหน้าจออุปกรณ์ในเครื่องของผู้ใช้
ไคลเอ็นต์: อุปกรณ์ของผู้ใช้ปลายทางที่ใช้ระบบปฏิบัติการ Android 9 Pie และบริการ Google Play หรือซอฟต์แวร์ที่รองรับเทียบเท่า
-
เฟรมเวิร์ก Android: เราใช้คำทั่วไปนี้ (หรือเพียงแค่เฟรมเวิร์ก) เพื่ออ้างอิงถึง API ใน Android 9 Pie ขึ้นไป และไม่ได้มีไว้เพื่ออ้างอิงถึงรุ่นก่อนหน้า
บริการ Google Play: ชุดบริการและแอปที่ทำงานในอุปกรณ์ของผู้ใช้ปลายทาง ซึ่งช่วยให้อุปกรณ์ทำงานร่วมกับระบบบัญชีของ Google และ API ของเซิร์ฟเวอร์ที่กำหนดเองได้
ตัวแทนการกู้คืน: แอปพลิเคชันระบบที่ทำงานเป็นส่วนหนึ่งของบริการ Google Play ในสเปซผู้ใช้บนอุปกรณ์ Android 9 Pie (หรือที่คล้ายกัน) ตัวแทนการกู้คืนมีหน้าที่รับผิดชอบในการใช้งานโปรโตคอลต่างๆ ฝั่งไคลเอ็นต์ และเพื่อเชื่อมต่อกับระบบปฏิบัติการ Android ตามที่จำเป็นในการสร้างข้อความโปรโตคอลที่เกี่ยวข้องกับ LSKF
การอ้างสิทธิ์การกู้คืน: เมื่อต้องการเรียกข้อมูลคีย์การกู้คืน ผู้ใช้ต้องสร้างการอ้างสิทธิ์การกู้คืนซึ่งมีสําเนาที่เข้ารหัสของ LSKF ที่ผู้ใช้อ้างว่าทราบ โดยปกติแล้ว ระบบจะขอให้ผู้ใช้ป้อน LSKF ของอุปกรณ์เครื่องเก่าในอุปกรณ์เครื่องใหม่ที่พยายามเข้าถึงคีย์การกู้คืนของอุปกรณ์เครื่องเก่า
คีย์การกู้คืน: คีย์ลับการเข้ารหัสที่ได้รับการปกป้องโดยบริการ Cloud Key Vault และใช้เพื่อเข้ารหัส (และตรวจสอบสิทธิ์) ข้อมูลในอุปกรณ์ไคลเอ็นต์ เมื่อใส่คีย์การกู้คืนลงในห้องนิรภัยแล้ว (ดูด้านล่าง) คุณจะลบสำเนาในเครื่องได้ทันทีที่ไคลเอ็นต์ใช้คีย์ดังกล่าวเพื่อเข้ารหัสข้อมูลเสร็จแล้ว
บริการ Cloud Key Vault (CKV): บริการอินเทอร์เน็ตที่ช่วยให้อุปกรณ์ไคลเอ็นต์จัดเก็บคีย์การเข้ารหัสที่ได้รับการปกป้องโดย LSKF ที่มนุษย์จำได้
-
กลุ่ม: คอลเล็กชันเซิร์ฟเวอร์ห้องนิรภัย/THM ที่ทำหน้าที่เป็นข้อมูลจำลองที่ซ้ำกันของกันและกันได้
คีย์สาธารณะของกลุ่ม: คีย์สาธารณะจากคู่คีย์ที่สร้างขึ้นโดยกลุ่ม THM ที่เฉพาะเจาะจง คีย์ส่วนตัวที่เกี่ยวข้องจะใช้ได้เฉพาะใน THM ที่อยู่ในกลุ่มประชากรตามรุ่น ณ เวลาที่สร้างคีย์เท่านั้น
Trusted Hardware Module (THM): โมดูลความปลอดภัยเฉพาะ (ไมโครคอนโทรลเลอร์) ที่ออกแบบมาเพื่อมอบสภาพแวดล้อมการประมวลผลที่เชื่อถือได้และน้อยที่สุด อย่างน้อยที่สุด องค์ประกอบที่ปลอดภัยต้องสร้างและ/หรือจัดเก็บคีย์ลับ รวมถึงรักษาสถานะที่เปลี่ยนแปลงได้แบบไม่ผันผวน (เพื่อป้องกันการโจมตีที่เกี่ยวข้องกับการรีเซ็ตเป็นสถานะก่อนหน้า)
ห้องนิรภัย: รายการหนึ่งๆ ในฐานข้อมูลของบริการ CKV ซึ่งมีคีย์การกู้คืนที่ได้รับการปกป้องด้วย LSKF ของอุปกรณ์เครื่องเดียว ผู้ใช้ปลายทางอาจมีห้องนิรภัยหลายห้องในระบบ โดยแต่ละห้องจะสอดคล้องกับอุปกรณ์หรือ LSKF ที่แตกต่างกัน มีเพียง THM ในเซิร์ฟเวอร์ห้องนิรภัยเท่านั้นที่สามารถตรวจสอบหรือดึงข้อมูลออกจากห้องนิรภัยได้
เซิร์ฟเวอร์ห้องนิรภัย: คอมพิวเตอร์อเนกประสงค์ที่ทำงานในศูนย์ข้อมูลของ Google ซึ่งได้รับการดัดแปลงเป็นพิเศษเพื่อเพิ่มโมดูลฮาร์ดแวร์ที่น่าเชื่อถือ (THM)
การออกแบบโปรโตคอล
โปรโตคอล CKV ประกอบด้วยหลายระยะ ดังนี้
การเริ่มต้น
Google จะระบุคีย์สาธารณะสำหรับ "รูทของความน่าเชื่อถือ" ที่เฟรมเวิร์กจะใช้เพื่อยืนยันการรับรองฮาร์ดแวร์ของ Google เพื่อเริ่มต้นระบบ คีย์การรับรองสำหรับรูทของความน่าเชื่อถือนี้จะจัดเก็บแบบออฟไลน์และรักษาความปลอดภัยอย่างระมัดระวัง โดยจะต้องให้พนักงานหลายคนเข้าร่วมเพื่อลงนามด้วยคีย์ดังกล่าว คีย์สาธารณะสำหรับรูทของความน่าเชื่อถือนี้ฝังอยู่ในระบบปฏิบัติการ Android และสามารถเปลี่ยนแปลงได้ผ่านการอัปเดตระบบปฏิบัติการเท่านั้น
นอกจากนี้ Google ยังเผยแพร่รายการคีย์สาธารณะของกลุ่ม THM แต่ละกลุ่มเป็นระยะๆ พร้อมกับการรับรองในรายการ การรับรองในรายการใช้ลายเซ็นที่เชื่อมโยงกลับไปยังรูทของความน่าเชื่อถือ การอัปเดตรายการที่เผยแพร่แต่ละรายการจะมีหมายเลขลำดับด้วย เพื่อป้องกันการย้อนกลับ ตัวแทนการกู้คืนจะดึงข้อมูลคีย์สาธารณะของกลุ่มประชากรตามรุ่นที่เผยแพร่ล่าสุดและส่งไปยังเฟรมเวิร์ก จากนั้นเฟรมเวิร์กจะยืนยันการรับรองและเลือกคีย์สาธารณะของกลุ่มประชากรตามรุ่นแบบสุ่มจากรายการเพื่อใช้ในขั้นตอนการสร้างห้องนิรภัย
การสร้างห้องนิรภัย
หลังจากช่วยให้เฟรมเวิร์กเริ่มต้นได้สําเร็จโดยการดึงข้อมูลรายการคีย์สาธารณะของกลุ่มประชากรตามรุ่นแล้ว ตัวแทนการกู้คืนจะขอให้เฟรมเวิร์กสร้างห้องนิรภัยใหม่ เมื่อใดก็ตามที่ผู้ใช้ป้อน LSKF อีกครั้ง เฟรมเวิร์กจะสร้างคีย์การกู้คืนใหม่และเข้ารหัสคีย์นั้นด้วยคีย์ที่มาจากแฮชของ LSKF ก่อน จากนั้นจึงเข้ารหัสด้วยคีย์สาธารณะของกลุ่มประชากรตามรุ่นที่เฟรมเวิร์กเลือกไว้ระหว่างการเริ่มต้นใช้งาน Blob ที่เข้ารหัสที่ได้คือห้องนิรภัยที่เฟรมเวิร์กส่งกลับไปยังตัวแทนการกู้คืน จากนั้นตัวแทนจะอัปโหลดไปยังบริการ CKV ของ Google
การเปิดตัวห้องนิรภัย
เมื่อตัวแทนการกู้คืนในอุปกรณ์เครื่องใหม่ต้องการเข้าถึงคีย์การกู้คืนที่จัดเก็บไว้ในห้องนิรภัยหนึ่งๆ ระบบจะแจ้งให้ผู้ใช้ป้อน LSKF ของอุปกรณ์เครื่องเดิมที่สร้างห้องนิรภัยนั้น จากนั้นตัวแทนการกู้คืนจะขอให้เฟรมเวิร์กสร้างการอ้างสิทธิ์การกู้คืนโดยใช้ LSKF ดังกล่าว เฟรมเวิร์กจะสร้างคีย์ผู้อ้างสิทธิ์ใหม่ และเข้ารหัสคีย์ผู้อ้างสิทธิ์ดังกล่าวรวมถึงแฮชของ LSKF ที่อ้างสิทธิ์ด้วยคีย์สาธารณะของกลุ่มประชากรตามรุ่นเดียวกันกับที่ใช้เข้ารหัสห้องนิรภัยในตอนแรก Blob ที่เข้ารหัสที่ได้นี้เรียกว่าการอ้างสิทธิ์การกู้คืน และเฟรมเวิร์กจะส่งต่อข้อมูลนี้ไปยังตัวแทนการกู้คืน ซึ่งจะแสดงข้อมูลดังกล่าวต่อบริการ CKV
CKV จะกำหนดเส้นทางการอ้างสิทธิ์การกู้คืน (และห้องนิรภัยที่เกี่ยวข้อง) ไปยังเซิร์ฟเวอร์ห้องนิรภัยที่เป็นส่วนหนึ่งของกลุ่มประชากรตามรุ่นที่ถูกต้อง จากนั้น THM ในเซิร์ฟเวอร์ของห้องนิรภัยจะถอดรหัสการอ้างสิทธิ์การกู้คืนและพยายามดึงคีย์การกู้คืนจากห้องนิรภัยเดิมโดยใช้แฮช LSKF ที่อ้างสิทธิ์ (เพื่อดึงคีย์การเข้ารหัสภายใน) หากแฮช LSKF เดิมและแฮช LSKF ที่อ้างสิทธิ์ตรงกัน THM จะดึงคีย์การกู้คืนออกจากห้องนิรภัยและเข้ารหัสอีกครั้งด้วยคีย์ของผู้อ้างสิทธิ์ที่อยู่ในการอ้างสิทธิ์การกู้คืน หากไม่ THM จะเพิ่มตัวนับการพยายามที่ไม่สำเร็จ เมื่อตัวนับความพยายามที่ไม่สำเร็จถึงขีดจำกัด THM จะปฏิเสธที่จะประมวลผลการอ้างสิทธิ์การกู้คืนในห้องนิรภัยนี้อีก
สุดท้าย หากทุกอย่างเรียบร้อยดี ระบบจะส่งคีย์การกู้คืนที่เข้ารหัสอีกครั้ง (ซึ่งตอนนี้เข้ารหัสภายใต้คีย์ผู้อ้างสิทธิ์) จากเซิร์ฟเวอร์ของห้องนิรภัยกลับไปที่เฟรมเวิร์ก เฟรมเวิร์กจะใช้สำเนาคีย์ผู้อ้างสิทธิ์เพื่อถอดรหัสคีย์การกู้คืน และโปรโตคอลจะเสร็จสมบูรณ์
มาตรการรักษาความปลอดภัย
ระบบ Cloud Key Vault มีเป้าหมายเพื่อมอบ "การป้องกันในเชิงลึก" โดยรวมการป้องกันความปลอดภัยไว้หลายระดับในสแต็กของเรา เราจะอธิบายวิธีการทำงานของการป้องกันเหล่านี้โดยเริ่มจากไคลเอ็นต์ แล้วค่อยๆ อธิบายลำดับชั้นขึ้นไปเรื่อยๆ จนไปถึงบริการ Cloud Key Vault
ความปลอดภัยของลูกค้า
โดยปกติแล้ว ปัจจัยความรู้ของหน้าจอล็อก (LSKF) จะจัดเก็บและป้องกันในอุปกรณ์โดยใช้วิธีการต่างๆ ที่ OEM แต่ละรายกำหนด ทั้งนี้ขึ้นอยู่กับ OEM และอุปกรณ์ ตัวอย่างเช่น อุปกรณ์ Pixel 2 ของ Google ใช้โมดูลความปลอดภัยฮาร์ดแวร์ที่ป้องกันการงัดแงะเพื่อจัดเก็บ LSKF ไว้ขณะไม่ได้ใช้งาน และบังคับใช้ขีดจำกัดอัตราตามฮาร์ดแวร์ในการตรวจสอบ LSKF Framework API ใหม่ที่เปิดตัวเพื่อเปิดใช้ Cloud Key Vault ได้รับการออกแบบมาเพื่อรักษาการรับประกันความปลอดภัยที่มีอยู่ให้ได้มากที่สุด แม้ว่าอุปกรณ์จะใช้โมดูลความปลอดภัยของฮาร์ดแวร์ดังกล่าวเพื่อปกป้องพื้นที่เก็บข้อมูลของ LSKF ก็ตาม
เราจะมุ่งเน้นที่ปัญหาด้านความปลอดภัยและการปกป้องที่เกี่ยวข้องซึ่งส่งผลต่อฟีเจอร์ Cloud Key Vault ใหม่โดยเฉพาะ แทนที่จะพยายามอธิบายภาพรวมของกลไกการรักษาความปลอดภัยทั้งหมดที่เกี่ยวข้องกับ LSKF
การรักษาความปลอดภัยให้กับ Framework API
Framework API ใหม่ที่เพิ่มเพื่อรองรับบริการ CKV จะมีการทำเครื่องหมายเป็น @SystemApi และต้องใช้สิทธิ์พิเศษ ซึ่งช่วยให้มั่นใจได้ว่า API เหล่านี้จะพร้อมให้บริการแก่แอประบบที่ได้รับอนุมัติจาก OEM เท่านั้น เช่น บริการ Google Play ซึ่งจะช่วยลดพื้นที่การโจมตีโดยตรงที่อาจเปิดเผยต่อแอปที่ผู้ใช้ติดตั้งในอุปกรณ์ได้อย่างมาก
นอกจากนี้ Framework API ยังตรวจสอบว่าระบบจะสร้างห้องนิรภัยสําหรับคีย์สาธารณะของกลุ่มประชากรตามรุ่นที่ได้รับการรับรองจากรูทของความน่าเชื่อถือเท่านั้น OEM จะฝังรูทของความน่าเชื่อถือไว้ในเฟรมเวิร์กเมื่อจัดส่ง และไม่สามารถเปลี่ยนแปลงได้หากไม่อัปเดตระบบปฏิบัติการ ซึ่งช่วยให้มั่นใจได้ว่ามีการใช้ LSKF เพื่อสร้างห้องนิรภัยที่จะบังคับใช้การป้องกันการบุกค้นด้วยวิธีถอดรหัสทั้งหมดโดยอิงตามฮาร์ดแวร์อย่างเหมาะสมเท่านั้น การใช้ THM ในบริการ Cloud Key Vault เพื่อการป้องกันการใช้กำลัง brute force สำหรับ LSKF จะช่วยให้เราบรรลุความปลอดภัยเทียบเท่ากับการใช้ฮาร์ดแวร์ที่มีความปลอดภัยในอุปกรณ์เพื่อดำเนินการเดียวกัน (เช่นเดียวกับที่อุปกรณ์ Google Pixel 2 ทำ)
เนื่องจากเราไม่คิดว่า LSKF จะจัดเก็บไว้ที่ใดก็ตามในอุปกรณ์นอกฮาร์ดแวร์ที่ปลอดภัย คุณจึงสร้างห้องนิรภัยใหม่ได้ทันทีหลังจากปลดล็อกอุปกรณ์เท่านั้น เมื่อผู้ใช้ป้อน LSKF เพื่อปลดล็อกอุปกรณ์ ระบบจะแสดง LSKF นั้นใน RAM ให้กับเฟรมเวิร์กเป็นระยะเวลาสั้นๆ นั่นคือเวลาที่ API ใหม่สำหรับสร้างห้องนิรภัยจะใช้ข้อมูลดังกล่าว คุณไม่สามารถสร้างห้องนิรภัยใหม่ที่ป้องกันด้วย LSKF ได้ขณะที่อุปกรณ์ล็อกอยู่ เนื่องจาก LSKF ไม่พร้อมใช้งาน
การรักษาความปลอดภัยให้กับตัวแทนการกู้คืน
การป้องกันความปลอดภัยหลักที่เรามอบให้ตัวแทนการกู้คืนคือโปรโตคอลได้รับการออกแบบมาเพื่อป้องกันไม่ให้ตัวแทนการกู้คืนเห็น LSKF ของอุปกรณ์ปัจจุบันหรือคีย์การกู้คืนใดๆ เฉพาะเฟรมเวิร์กเท่านั้นที่ควรเห็นข้อมูลดังกล่าวฝั่งไคลเอ็นต์ ซึ่งทำให้การใช้ประโยชน์จากข้อบกพร่องที่อาจเกิดขึ้นหรือช่องโหว่ด้านความปลอดภัยในเครื่องมือการกู้คืนทำได้ยากขึ้นมาก โดยส่วนใหญ่จะใช้ตัวแทนการกู้คืนเพื่อจัดการเหตุการณ์ในวงจรและการส่งข้อมูลไปมาระหว่างระบบคลาวด์กับเฟรมเวิร์ก ข้อยกเว้นเพียงอย่างเดียวที่เกิดขึ้นระหว่างการกู้คืนคือเมื่ออยู่ในช่วงก่อนใช้โปรโตคอลการเปิดห้องนิรภัย เมื่อผู้ใช้ต้องป้อน LSKF ของอุปกรณ์เครื่องเก่า โดย UI ที่รวบรวม LSKF ที่อ้างสิทธิ์สำหรับอุปกรณ์เครื่องเก่าจะติดตั้งใช้งานในเครื่องมือรับส่งข้อมูลสำหรับการกู้คืน4 อย่างไรก็ตาม การติดตั้งใช้งานตัวแทนการกู้คืนจะ "ลืม" LSKF ที่อ้างสิทธิ์ทันทีที่เฟรมเวิร์กเริ่มสร้างการอ้างสิทธิ์การกู้คืน
ฟีเจอร์ด้านความปลอดภัยของโปรโตคอล
แม้ว่าการวิเคราะห์โปรโตคอลอย่างละเอียดจะนอกเหนือขอบเขตของเอกสารนี้ แต่เราต้องการไฮไลต์การป้องกันบางอย่างที่มีอยู่ในโปรโตคอล โดยเฉพาะอย่างยิ่ง โปรโตคอลจะใช้เฉพาะแฮชของ LSKF ตลอด ซึ่งหมายความว่าหาก LSKF มีเอนโทรปีสูง (เช่น เป็นรหัสผ่านที่ดีซึ่งมีเอนโทรปีสูง) การจัดเก็บห้องนิรภัยจะดีกว่าการจัดเก็บแฮชรหัสผ่านอย่างเห็นได้ชัด และในกรณีนี้ แฮชรหัสผ่านจะวัดระดับความปลอดภัยได้โดยไม่ขึ้นอยู่กับความปลอดภัยของ THM ด้วยเหตุนี้ เราจึงรองรับการแฮช LSKF แบบ "จำได้ยาก" ที่มีเกลือเป็นส่วนหนึ่งของโปรโตคอล นอกจากนี้ เรายังเข้ารหัสและเชื่อมโยงห้องนิรภัยกับตัวระบุของอุปกรณ์ที่สร้างห้องนิรภัยนั้น และเชื่อมโยงการอ้างสิทธิ์การกู้คืนกับ Nonce ที่ใช้เป็นการยืนยันระหว่างโปรโตคอลการเปิดห้องนิรภัย เพื่อให้การอ้างสิทธิ์การกู้คืนเป็นข้อมูลล่าสุด
เนื่องจากระบบจะสร้างคีย์การกู้คืนใหม่ทุกครั้งที่สร้างห้องนิรภัย เราจึงใช้การเปลี่ยนคีย์โดยเขียนทับรายการห้องนิรภัยที่มีอยู่ด้วยห้องนิรภัยที่สร้างขึ้นใหม่ ระบบจะเลือกที่อยู่สำหรับตัวนับความพยายามที่ไม่สำเร็จซึ่งห้องนิรภัยใช้ในระหว่างการสร้างห้องนิรภัย และเฟรมเวิร์กจะตรวจสอบว่าที่อยู่ตัวนับที่ใช้สำหรับห้องนิรภัยที่สร้างขึ้นภายหลังจะไม่เปลี่ยนแปลง เว้นแต่จะมีการเปลี่ยนแปลง LSKF หรือมีรายการคีย์สาธารณะของกลุ่มประชากรตามรุ่นที่ผ่านการรับรองรายการใหม่ ดังนั้น การเปลี่ยนคีย์การกู้คืนจึงทำได้โดยไม่ส่งผลเสียต่อการป้องกันการโจมตีด้วยกำลัง brute force สำหรับ LSKF
ความปลอดภัยของเซิร์ฟเวอร์สําหรับบริการ Cloud Key Vault
เซิร์ฟเวอร์ติดตั้งใช้งานโดยใช้ซอฟต์แวร์ที่ทำงานบนฮาร์ดแวร์เซิร์ฟเวอร์ทั่วไป และเฟิร์มแวร์ที่ทำงานบนฮาร์ดแวร์เฉพาะ (ชิป Titan) เราจะอธิบายการป้องกันที่ให้บริการในแต่ละเลเยอร์
การปกป้องฮาร์ดแวร์
การป้องกันความปลอดภัยหลักที่ใช้ฝั่งเซิร์ฟเวอร์ของบริการ CKV คือโมดูลฮาร์ดแวร์ที่น่าเชื่อถือ (THM) ซึ่งสร้างขึ้นโดยใช้ชิป Titan ที่ออกแบบเองของ Google ชิปดังกล่าวใช้เฟิร์มแวร์ที่แสดง API ที่จำเป็นในการใช้งานโปรโตคอล CKV โดยเฉพาะอย่างยิ่ง ผู้ใช้สามารถสร้างและแชร์คู่คีย์กับสมาชิกคนอื่นๆ ในกลุ่มประชากรตามรุ่นได้อย่างปลอดภัย เพื่อให้ตรรกะเฟิร์มแวร์ปกป้องคีย์ส่วนตัวไม่ให้รั่วไหลออกไปนอกชิป Titan ในกลุ่มประชากรตามรุ่น นอกจากนี้ ยังดำเนินการเปิดห้องนิรภัยและรักษาตัวนับจำนวนครั้งที่พยายามไม่สำเร็จของห้องนิรภัยแต่ละห้องให้เพิ่มขึ้นอย่างเคร่งครัด (โดยตัวนับจะอิงตามสถานะที่เก็บไว้ในชิป Titan) คำอธิบายโดยละเอียดเพิ่มเติมเกี่ยวกับโปรโตคอลที่ดำเนินการโดยเฟิร์มแวร์ชิป CKV Titan จะระบุไว้ในเอกสารฉบับที่ออกในอนาคต
เนื่องจากความปลอดภัยของเซิร์ฟเวอร์มาจากตรรกะเฟิร์มแวร์ในชิป Titan เราจึงต้องตรวจสอบว่าตรรกะดังกล่าวไม่มีการเปลี่ยนแปลงในลักษณะที่อนุญาตให้ชิปรั่วไหลความลับหรือละเว้นขีดจำกัดตัวนับ และเพื่อบรรลุเป้าหมายนี้ เรายังแก้ไขบูตโหลดเดอร์ของ Titan เพื่อให้แน่ใจว่าข้อมูลที่จัดเก็บไว้ในชิป (เช่น คีย์ส่วนตัวสำหรับกลุ่มประชากรตามรุ่น) จะถูกลบออกอย่างสมบูรณ์ก่อนที่จะมีการอัปเดต ข้อเสียของการปกป้องนี้คือเราไม่สามารถแก้ไขข้อบกพร่องในเฟิร์มแวร์ได้โดยไม่สูญเสียข้อมูลบางส่วน การอัปเดตเฟิร์มแวร์เทียบเท่ากับการทำลายฮาร์ดแวร์ที่มีอยู่และแทนที่ด้วยชิปใหม่ ในกรณีที่จำเป็นต้องมีการแก้ไขข้อบกพร่องร้ายแรงของเฟิร์มแวร์ Google จะต้องสร้างและเผยแพร่รายการคีย์สาธารณะของกลุ่มประชากรตามรุ่นที่ได้รับการรับรองใหม่ทั้งหมด และย้ายข้อมูลผู้ใช้ทั้งหมดไปยังรายการใหม่ทีละน้อย เราพยายามลดความเสี่ยงนี้โดยพยายามทำให้โค้ดเบสของเฟิร์มแวร์มีขนาดเล็กที่สุด และตรวจสอบอย่างละเอียดเพื่อหาปัญหาด้านความปลอดภัยที่อาจเกิดขึ้น
การป้องกันซอฟต์แวร์
นอกจากขีดจำกัดการหยุดทำงานสูงสุดต่อห้องนิรภัยที่ THM กำหนดแล้ว บริการ CKV ยังใช้การจำกัดอัตราการส่งข้อมูลโดยซอฟต์แวร์ด้วย การจำกัดอัตราการดำเนินการออกแบบมาเพื่อป้องกันไม่ให้ผู้ลักลอบใช้บัญชีเข้าถึงบัญชีของผู้ใช้และพยายามกู้คืนไม่สำเร็จจนหมดขีดจำกัดอย่างรวดเร็ว ซึ่งจะล็อกไม่ให้ผู้ใช้จริงเข้าถึงคีย์การกู้คืนของตนได้ เช่นเดียวกับการหน่วงเวลาของอุปกรณ์ของผู้ใช้หลังจากพยายามปลดล็อกหน้าจอไม่สำเร็จหลายครั้งเกินไป บริการ CKV จะบังคับใช้การหน่วงเวลาที่เพิ่มขึ้นหลังจากคำขอเปิดห้องนิรภัยไม่สำเร็จแต่ละครั้ง
นอกจากนี้ เรายังใช้มาตรการรักษาความปลอดภัยมาตรฐานสำหรับบริการระบบคลาวด์ที่โฮสต์ข้อมูลผู้ใช้ ซึ่งรวมถึงการควบคุมการเข้าถึง การตรวจสอบ และการตรวจสอบที่เข้มงวด
ข้อมูลจำเพาะของโปรโตคอลโดยละเอียด
ข้อกำหนดโปรโตคอลแบบละเอียดยังอยู่ระหว่างดำเนินการ และเอกสารนี้จะได้รับการอัปเดตให้รวมรายละเอียดเหล่านั้นไว้ด้วย พร้อมกับการเผยแพร่โค้ดไคลเอ็นต์ในโปรเจ็กต์โอเพนซอร์ส Android ภายในปีนี้
หมายเหตุ
- "Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX" 1 ส. ค.2014 https://www.usenix.org/node/184458 ↩
- "บล็อก Google Cloud Platform: เจาะลึกเกี่ยวกับ Titan: การรักษาความปลอดภัยในรูปแบบข้อความธรรมดา" 24 ส. ค.2017 https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html ↩
- "Google ประกาศว่ามีอุปกรณ์ที่ใช้งานอยู่มากกว่า 2 พันล้านเครื่องต่อเดือนใน Android ...." 17 พฤษภาคม 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users ↩
- วิธีนี้ช่วยให้เราให้บริการ UI ที่ยืดหยุ่นสำหรับการป้อน LSKF ของอุปกรณ์เครื่องอื่นได้ เนื่องจากเฟรมเวิร์กของอุปกรณ์ปัจจุบันอาจไม่มี UI ที่เหมาะสมสำหรับการป้อน LSKF ของอุปกรณ์เครื่องเก่า ↩