Score:2

สามารถใช้แท็กการตรวจสอบสิทธิ์ AES-GCM เป็นฟังก์ชันรับคีย์ได้หรือไม่

ธง na

ฉันต้องการสร้างแผนผังการสืบทอดคีย์เชิงกำหนด โดยที่รูทถูกเก็บไว้อย่างปลอดภัยในบริการส่วนกลาง และลีฟถูกฝังอยู่ในอุปกรณ์จำนวนมาก เมื่ออุปกรณ์ต้องการสื่อสารกับแบ็คเอนด์ อุปกรณ์จะระบุ ID และเกลือ และบริการแบบรวมศูนย์จะรับคีย์เฉพาะอุปกรณ์จากรูทคีย์และ ID อุปกรณ์และเกลือ

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

Azure Key Vault มีการสนับสนุนแบบทดลองสำหรับ AES-GCM บน HSM ที่มีการจัดการ ความคิดของฉันคือการใช้เกลืออุปกรณ์เป็นอินพุต nonce (IV) ของ AES-GCM และ ID อุปกรณ์เป็นอินพุตข้อมูลที่เกี่ยวข้องและไม่มีข้อความธรรมดาเป็นอินพุต ในฐานะเอาต์พุตของ AES-GCM ฉันจะใช้แท็กที่สร้างขึ้นเป็นคีย์สุ่มหลอกเชิงกำหนด:

$\text{KDF}(คีย์, เกลือ, id) := \text{AES-GCM-encryption}(คีย์, \epsilon, เกลือ, id)$

ที่ไหน $คีย์$ เป็นความลับรูทส่วนกลางที่จัดเก็บไว้ในห้องเก็บกุญแจ $\epsilon$ เป็นสตริงว่างที่ใช้เป็นอินพุต GCM แบบข้อความธรรมดา $เกลือ$ เป็นค่า 96 บิตที่ใช้เป็น $ไม่นอน$ ใน GCM และ $id$ เป็นสตริงที่ระบุอุปกรณ์ที่มีความยาวผันแปรซึ่งไม่มีอุปกรณ์ใดแชร์กับอุปกรณ์อื่นและใช้เป็นอินพุตข้อมูลที่เกี่ยวข้องใน GCM

การก่อสร้างนั้นปลอดภัยหรือไม่?

  • สมมติว่า เกลือ / nonce มีเอกลักษณ์เฉพาะตัวทั่วโลก ตลอดอายุการใช้งานของคีย์และรหัสอุปกรณ์ทั้งหมดหรือไม่
  • สมมติว่า เกลือ / "nonce" ไม่ซ้ำกันสำหรับ ID ที่ระบุเท่านั้น และอาจมีอุปกรณ์หลายอย่างที่ใช้เกลือเดียวกันโดยไม่ได้ตั้งใจ (เนื่องจากการชนกันของค่าสุ่ม)?

โดยสัญชาตญาณ ฉันค่อนข้างมั่นใจว่าด้วยเกลือที่ไม่เหมือนใครทั่วโลก โครงสร้างนี้ควรเป็นฟังก์ชันการได้มาของคีย์ที่ปลอดภัย แต่สิ่งนี้ทำได้ยากสำหรับกรณีการใช้งานที่เราคิดไว้

Maarten Bodewes avatar
in flag
คุณใช้ nonce เป็นคีย์หรือไม่? มันควรจะมีขนาด 128 บิตไม่ใช่หรือ แล้วทำไมคุณถึงเรียกมันว่า nonce ถ้ามันเป็นกุญแจล่ะ? สร้าง / จัดการอย่างไร
Perseids avatar
na flag
แย่จัง ฉันกังวลกับส่วนที่เหลือมากจนลืมข้อมูลสำคัญในสูตรnonce เป็นเกลือในระบบการตั้งชื่อ HKDF และจริงๆ แล้วมีคีย์ที่สร้างและสำรองไว้ภายนอก Key Vault และจัดเก็บไว้ใน Key Vault ที่ไม่สามารถส่งออกได้
Perseids avatar
na flag
โอ้ และผลข้างเคียงที่น่าเสียดายอีกอย่างของการตั้งค่านี้คือระดับที่สองของแผนผัง (เช่น ผลลัพธ์ของการสืบทอดครั้งแรก) ออกจากสภาพแวดล้อมที่ปลอดภัยแล้ว ตามหลักการแล้ว แอ็พพลิเคชันเซิร์ฟเวอร์จะจัดเตรียมเฉพาะข้อมูลเส้นทาง (รหัสและเกลือสำหรับแต่ละแหล่งที่มา) แต่ฉันไม่เห็นวิธีการดำเนินการดังกล่าวหากไม่มีการสนับสนุนการสืบทอดคีย์พิเศษของสภาพแวดล้อมที่ปลอดภัย (HSM เฉพาะส่วนใหญ่จะสามารถทำได้ แต่ไม่ใช่อินเทอร์เฟซที่มีการจัดการที่ผู้ให้บริการระบบคลาวด์มีให้)
Score:3
ธง us

ขั้นแรกให้กำหนดการก่อสร้าง AES-GCM เมื่อใช้ในลักษณะที่แนะนำจะเทียบเท่ากับ $$\operatorname{KDF}(K,S,I)=\operatorname{AES}_K(S\|0^{32})\oplus \operatorname{GHASH}_{\operatorname{AES}_K(0^{ 128})}(ฉัน)$$

ที่ไหน $\ชื่อผู้ประกอบการ{GHASH}_H(M)\ประมาณ \sum_i H^iM_i$ สำหรับบล็อกข้อความ $M_i$ ที่มีขนาด 128 บิตและการคูณและการเพิ่มที่ทำในฟิลด์จำกัดขนาด 128 บิตที่มีการแทนชื่อพหุนาม นี่เป็นค่าประมาณของ GHASH ที่จะใช้ได้กับการสนทนาด้านล่างของเรา

การก่อสร้างนั้นปลอดภัยหรือไม่?

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

[สมมติว่า] เกลือ / nonce นั้นไม่ซ้ำกันทั่วโลกตลอดอายุการใช้งานของคีย์และรหัสอุปกรณ์ทั้งหมด?

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

[สันนิษฐาน] เกลือ / "nonce" นั้นไม่ซ้ำกันสำหรับ ID ที่ระบุเท่านั้น และอาจมีอุปกรณ์หลายเครื่องที่ใช้เกลือเดียวกันโดยบังเอิญ (เนื่องจากการชนกันของค่าสุ่ม)?

น่าเสียดายที่ไม่มี ถ้าสองรากศัพท์ใช้เหมือนกัน $(K,S)$ จับคู่กับสองที่แตกต่างกัน $ฉัน ฉัน'$ แบบสอบถามและฝ่ายตรงข้ามเรียนรู้คีย์ผลลัพธ์ที่เกี่ยวข้อง $k,k'$จากนั้นศัตรูสามารถเรียนรู้ได้ $k\oplus k' = \operatorname{GHASH}_{\operatorname{AES}_K(0^{128})}(I) \oplus \operatorname{GHASH}_{\operatorname{AES}_K(0^{ 128})}(I')\ประมาณ \sum_i H^i(I'_i\oplus I_i)$ ซึ่งเป็นสำนวนที่ศัตรูสามารถฟื้นตัวได้ $H=\ชื่อผู้ประกอบการ{AES}_K(0^{128})$ ทำให้พวกเขาฟื้นตัวได้ $k\oplus \operatorname{GHASH}_{\operatorname{AES}_K(0^{128})}(I) = \operatorname{AES}_K(S\|0^{32})$ และจากนั้นทำนายคีย์ที่ได้มาสำหรับสิ่งใด ๆ $I$ สำหรับการแก้ไขนี้ $(K,S)$ คู่.

โพสต์คำตอบ

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