การเข้ารหัสจากต้นทางถึงปลายทางด้วย Signal Protocol และ AES-256 ทุกส่วน
Sanket (Sanket.Chat) โดย Tosh Defence เข้ารหัสทุกข้อความ การแสดงความรู้สึกตอบกลับ และข้อความกระจายที่เข้ารหัสแบบต้นทางถึงปลายทางด้วย Signal Protocol ผ่าน libsignal ฉบับทางการของ Signal ที่ผ่านการตรวจสอบอย่างอิสระ โดยใช้การตกลงกุญแจ PQXDH และ Double Ratchet ร่วมกับ SPQR ไฟล์ เฟรมของการโทร การรับส่งข้อมูลการโทร พื้นที่จัดเก็บข้อมูลภายในเครื่อง และทุกเซสชัน TLS ที่ระบบติดตั้งเป็นปลายทาง ใช้ AES-256 โดยไม่มีการสลับไปใช้ AES-128 และไม่มีโหมดความเข้ากันได้
ใช้เออีเอส-256 มิฉะนั้นไม่ดำเนินการ คือแนวทางทางวิศวกรรมของ Sanket ที่บังคับใช้ในโค้ด หากไม่สามารถเข้ารหัสได้ตรงตามที่ออกแบบไว้ทุกประการ ระบบจะปฏิเสธการดำเนินการแทนการลดระดับการป้องกัน
ข้อความ: Signal Protocol โดยไม่มีการดัดแปลง
SANKET ใช้ไลบรารี libsignal ฉบับทางการของ Signal สำหรับการเข้ารหัสข้อความทั้งหมด โดยใช้รุ่นเผยแพร่เดียวกันบน iOS, Android คอมพิวเตอร์ และเซิร์ฟเวอร์ ไม่มีการนำ Signal Protocol มาพัฒนาใหม่ และไม่มีอัลกอริทึมเข้ารหัสข้อความทางเลือก
เซสชันเริ่มต้นด้วย PQXDH ซึ่งเป็นส่วนขยายของ X3DH สำหรับความปลอดภัยหลังยุคควอนตัม โดยผสานการตกลงกุญแจด้วย X25519 เข้ากับการห่อหุ้มกุญแจแบบ Kyber จากนั้นข้อความจะเข้ารหัสด้วย Double Ratchet โดยขยายกุญแจของแต่ละข้อความออกเป็นกุญแจ AES-256 กุญแจ HMAC-SHA256 และเวกเตอร์เริ่มต้น (IV) ข้อความจะเข้ารหัสด้วย AES-256 และตรวจสอบความถูกต้องด้วย HMAC-SHA256 ก่อนลบกุญแจหลังใช้งาน นอกจากนี้แรตเชตหลังยุคควอนตัมแบบเบาบางของ Signal ยังทำงานควบคู่กันในทุกเซสชัน
ออกแบบมาให้ไม่มีวิธีสำรอง
แอปฝั่งผู้ใช้จะไม่ส่งข้อความหากไม่สามารถเข้ารหัสด้วย libsignal ได้ อุปกรณ์ที่ไม่เผยแพร่คีย์ยืนยันตัวตนของ libsignal จะถูกข้ามแทนการส่งเป็นข้อความที่ไม่เข้ารหัส ตัวบ่งชี้ข้อความที่ไม่เข้ารหัสของระบบเดิมจะถูกปฏิเสธ และเซิร์ฟเวอร์จะปฏิเสธชุดคีย์ที่ไม่เป็นไปตามรูปแบบของ libsignal ไม่มีช่องทางส่งเนื้อหาข้อความแบบไม่เข้ารหัสหรือด้วยวิธีเข้ารหัสอื่น
กลุ่มที่ไม่มีคีย์ร่วมกัน
ข้อความกลุ่มเข้ารหัสด้วยวิธีส่งแยกเป็นคู่: อุปกรณ์ของผู้ส่งเข้ารหัสข้อความแยกต่างหากสำหรับอุปกรณ์ที่เชื่อถือได้ทุกเครื่องของสมาชิกแต่ละราย โดยผ่านเซสชัน libsignal ของอุปกรณ์แต่ละเครื่อง การเปลี่ยนแปลงสมาชิกไม่จำเป็นต้องสร้างกุญแจเข้ารหัสใหม่ และสมาชิกที่ถูกนำออกก็จะไม่อยู่ในรายชื่อผู้รับที่ส่งข้อความแยกไปให้อีกต่อไป.
ก่อนเข้ารหัส ผู้ส่งจะตรวจสอบรายการอุปกรณ์ของบัญชีผู้รับแต่ละราย ซึ่งลงลายมือชื่อด้วยกุญแจของบัญชีนั้นเอง และจะไม่ส่งข้อมูลใด ๆ ไปยังอุปกรณ์ที่ไม่อยู่ในรายการ
ไฟล์และการโทร
เนื้อหา ชื่อ และประเภทของไฟล์แนบถูกเข้ารหัสบนอุปกรณ์ด้วย AES-256-GCM โดยใช้กุญแจสุ่มขนาด 256 บิตแยกสำหรับแต่ละไฟล์ และกุญแจนั้นถูกส่งไปภายในข้อความของ libsignal
เสียงและวิดีโอได้รับการปกป้อง 2 ชั้น เฟรมของผู้เข้าร่วมแต่ละรายเข้ารหัสตั้งแต่ต้นทางถึงปลายทางด้วย AES-256-GCM โดยใช้กุญแจเฉพาะผู้ส่งที่เปลี่ยนตามกลไกแรตเชตทุก 200 มิลลิวินาที ทำให้ผู้ส่งแต่ละรายมีกุญแจเฟรมใหม่ 5 ดอกต่อวินาที และมีการสร้างกุญแจแบบสุ่มใหม่ทุกครั้งที่มีผู้เข้าร่วมหรือออกจากการโทร ระหว่างอุปกรณ์แต่ละเครื่องกับเซิร์ฟเวอร์สื่อ SRTP ยอมรับเฉพาะ AEAD_AES_256_GCM เซิร์ฟเวอร์สื่อส่งต่อเฟรมที่เข้ารหัสโดยไม่สามารถถอดรหัสได้ และการออกแบบนี้ไม่รองรับการบันทึกการโทรฝั่งเซิร์ฟเวอร์
- ใช้ AES-256-GCM สำหรับแต่ละไฟล์
- กุญแจเข้ารหัสการโทรแยกตามผู้ส่ง ไม่ใช้กุญแจร่วมกันทั้งห้อง
- คีย์สำหรับเฟรม 5 รายการต่อวินาทีต่อผู้ส่ง
- ใช้เฉพาะ SRTP AES-256-GCM
การส่งผ่านและการจัดเก็บข้อมูล
ทุกการเชื่อมต่อของไคลเอนต์ใช้ TLS 1.3 กับ TLS_AES_256_GCM_SHA384 หรือใช้ TLS 1.2 กับ ECDHE และ AES-256-GCM สำหรับชุดเครือข่ายของแพลตฟอร์มที่จำเป็นต้องใช้รูปแบบนี้ โดยไม่ใช้ AES-128, ChaCha20, ชุดรหัสลับโหมด CBC และ RSA แบบคงที่ และเสนอ X25519MLKEM768 ซึ่งเป็นกลุ่มแบบผสมสำหรับการป้องกันภัยจากคอมพิวเตอร์ควอนตัมเป็นตัวเลือกแรก อุปกรณ์ที่ได้รับอนุมัติทุกเครื่องยังสามารถพิสูจน์ตัวตนด้วยใบรับรองฝั่งไคลเอนต์ของตนเองผ่าน TLS แบบยืนยันตัวตนซึ่งกันและกัน
บนอุปกรณ์ ฐานข้อมูลภายในเครื่องเข้ารหัสด้วย AES-256 และตรวจสอบความถูกต้องด้วย HMAC-SHA256 ส่วนบนโทรศัพท์ ที่เก็บข้อมูลโปรโตคอลและข้อมูลลับของอุปกรณ์เข้ารหัสด้วยกุญแจที่ได้รับการปกป้องด้วยฮาร์ดแวร์ใน Secure Enclave, StrongBox หรือสภาพแวดล้อมการประมวลผลที่เชื่อถือได้
หลักฐานยืนยันทางเทคนิค
อ่านรายละเอียดในเอกสารไวต์เปเปอร์ของ Sanket
ทุกข้อความที่ระบุในหน้านี้มีรายละเอียดฉบับเต็มอยู่ในเอกสารเผยแพร่ด้านความปลอดภัยทางเทคนิคและสถาปัตยกรรมของ Sanket ซึ่งอ่านได้ฟรีโดยไม่ต้องลงทะเบียน
SANKET ใช้ Signal Protocol หรือไม่?
ใช่ SANKET เข้ารหัสข้อความทั้งหมดด้วยไลบรารี libsignal อย่างเป็นทางการของ Signal บนทุกแพลตฟอร์ม โดยใช้การตกลงกุญแจแบบ PQXDH และ Double Ratchet ร่วมกับ SPQR และไม่มีการสร้างโพรโทคอลขึ้นใหม่แยกต่างหาก
การส่งข้อความของ SANKET เข้ารหัสด้วย AES-256 หรือไม่?
ใช่ ข้อความใช้ AES-256-CBC ร่วมกับ HMAC-SHA256 ภายใน libsignal ส่วนไฟล์ เฟรมการโทร การส่งข้อมูลการโทร พื้นที่จัดเก็บข้อมูลในเครื่อง และ TLS ใช้ AES-256-GCM โดยไม่มีการสลับไปใช้ AES-128
การโทรด้วยเสียงและวิดีโอเข้ารหัสแบบต้นทางถึงปลายทางหรือไม่?
ใช่ เฟรมของการโทรเข้ารหัสจากต้นทางถึงปลายทางด้วย AES-256-GCM โดยใช้คีย์แยกตามผู้ส่งที่ส่งผ่าน libsignal พร้อมคีย์เข้ารหัสเฟรมใหม่ 5 คีย์ต่อวินาทีสำหรับผู้ส่งแต่ละราย ภายใน SRTP ที่ยอมรับเฉพาะ AES-256-GCM
การแสดงปฏิกิริยาและข้อความกระจายข่าวได้รับการเข้ารหัสหรือไม่?
ใช่ การตอบสนองต่อข้อความและการกระจายข้อความที่เข้ารหัสเป็นข้อความของ libsignal ซึ่งเข้ารหัสตั้งแต่ต้นทางถึงปลายทางเช่นเดียวกับข้อความอื่นทุกข้อความ ระดับความสำคัญ กำหนดเวลา และเวลาหมดอายุของข้อความกระจายก็อยู่ภายในการเข้ารหัสด้วย
SANKET ใช้กุญแจผู้ส่งสำหรับกลุ่มหรือไม่?
ไม่ SANKET เข้ารหัสข้อความกลุ่มแยกต่างหากสำหรับอุปกรณ์ที่เชื่อถือได้ทุกเครื่องของสมาชิกทุกคน โดยแต่ละเครื่องใช้เซสชัน libsignal ของตนเอง จึงไม่มีกุญแจเข้ารหัสร่วมของกลุ่ม.
Sanket รองรับ TLS เวอร์ชันใดบ้าง?
ใช้ TLS 1.3 เป็นตัวเลือกหลัก โดยรองรับเฉพาะ TLS_AES_256_GCM_SHA384 ส่วน TLS 1.2 ยอมรับเฉพาะเมื่อใช้ ECDHE และ AES-256-GCM ไม่ยอมรับรุ่นที่ต่ำกว่า TLS 1.2 และเสนอการแลกเปลี่ยนกุญแจแบบผสมผสานที่ทนต่อคอมพิวเตอร์ควอนตัม X25519MLKEM768 เป็นตัวเลือกแรก
libsignal ผ่านการตรวจสอบแล้วหรือไม่?
ใช่ SANKET สร้างขึ้นโดยใช้ไลบรารี libsignal ของ Signal ที่ผ่านการตรวจสอบอิสระ และโปรโตคอล PQXDH ผ่านการวิเคราะห์อย่างเป็นทางการแล้ว
ตรวจสอบวิทยาการเข้ารหัสของ SANKET ร่วมกับวิศวกรของเรา
Tosh Defence อธิบายการออกแบบระบบเข้ารหัสทีละชั้นแก่สถาปนิกด้านความปลอดภัยและคณะกรรมการประเมิน โดยมีเอกสารทางเทคนิคฉบับควบคุมการเข้าถึงให้ภายใต้ข้อตกลงการไม่เปิดเผยข้อมูล