กูเกิลเปิดเอกสารรายละเอียดในภาพใหญ่ของกระบวนการเข้ารหัสระหว่างบริการภายใน Application Layer Transport Security (ALTS) ที่ใช้ยืนยันตัวตนระหว่างบริการต่างๆ ของกูเกิลเอง
กูเกิลระบุว่าเหตุผลที่ต้องออกแบบ ATLS มาใช้งานเอง คือ การยืนยันที่ระดับแอปพลิเคชั่น ในขณะที่การเชื่อมต่อ TLS นั้นมักเป็นการยืนยันตัวตนในระดับเครื่อง, กระบวนการกลับมาส่งข้อมูลหลังเชื่อมต่อครั้งแรกไปแล้ว เพราะบริการภายในของกูเกิลมีการเรียกข้อมูลระหว่างเครื่องซ้ำๆ จำนวนมาก, และการลดค่าใช้จ่ายในการเข้ารหัสเมื่อต้องเปิดช่องทางเรียกข้อมูลเป็นเวลานานๆ
ATLS บังคับว่าข้อมูลต้องมีการตรวจสอบความถูกต้อง (intregrity) เสมอ แต่อาจจะเลือกเข้ารหัสลับหรือไม่ก็ได้ โดยกระบวนการยืนยันความถูกต้องของข้อมูลที่ใช้คือ AES-GMAC หรือ AES-VMAC แต่หากข้อมูลเชื่อมต่อข้ามศูนย์ข้อมูล จะบังคับเข้ารหัสเสมอ
นอกการออกแบบในระดับโปรโตคอลแล้ว ATLS ยังอาศัยการแปลงข้อมูลเป็นสตรีม (serialize) ด้วย Protocol Buffer (protobuf) ของกูเกิลเอง แทนที่จะเป็น ASN.1 ใน TLS เพื่ออาศัยโครงสร้าง protobuf ที่กูเกิลใช้งานอยู่แล้ว
โค้ดของ ATLS ไม่ได้เปิดให้ภายนอกใช้งาน แต่เป็นการเปิดรายละเอียดเพื่อแสดงให้เห็นกระบวนการทำงานภายในของกูเกิลบางส่วนเท่านั้น
ที่มา - Google Security, Google Cloud
Comments
(หัวข้อ) ATLS > ของกระบวนการเข้ารหัสระหว่างบริการภายใน Application Layer Transport Security (ALTS)