การโจมตีแบบไซด์แชนเนล EUCLEAK ที่มุ่งเป้าไปยัง YubiKey ซีรีส์ 5

 (ninjalab.io)
1 คะแนน โดย GN⁺ 2024-09-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ขณะที่ secure element ถูกใช้เป็นฐานความเชื่อถือของการยืนยันตัวตนที่แข็งแกร่ง EUCLEAK คือการโจมตีแบบไซด์แชนเนลที่ดึงคีย์ลับออกจากการติดตั้งใช้งาน ECDSA ของ Infineon และได้สาธิตบน YubiKey 5Ci
  • ช่องโหว่หลักคือ การคำนวณ modular inverse แบบไม่คงที่ตามเวลา ในไลบรารีเข้ารหัสของ Infineon และได้ผ่านการประเมินรับรอง Common Criteria ระดับสูงสุดมาราว 80 ครั้งตลอด 14 ปี
  • ผู้โจมตีต้อง เข้าถึงทางกายภาพ กับ secure element และต้องใช้การวัดคลื่นแม่เหล็กไฟฟ้าในเครื่องเพียงไม่กี่ครั้ง พร้อมอุปกรณ์ราคาแพง ซอฟต์แวร์ปรับแต่งเฉพาะ และทักษะทางเทคนิค แต่การวัดจริงใช้เวลาเพียงไม่กี่นาที
  • ขอบเขตผลกระทบครอบคลุม YubiKey 5 Series ที่มีเฟิร์มแวร์ต่ำกว่า 5.7 และ secure microcontroller ที่รันไลบรารีเข้ารหัสของ Infineon รวมถึง TPM
  • ใน FIDO การดึงคีย์ลับ ECDSA ออกมาได้ทำให้ โคลนอุปกรณ์ ได้ แต่ในแง่การป้องกันฟิชชิง การใช้ผลิตภัณฑ์ที่ได้รับผลกระทบก็ยังปลอดภัยกว่าการไม่ใช้เลย

จุดที่การโจมตี EUCLEAK มุ่งเป้า

  • secure element คือไมโครคอนโทรลเลอร์ขนาดเล็กที่สร้างและเก็บค่าลับ รวมถึงดำเนินการคำนวณเข้ารหัส และมักได้รับการประเมินความปลอดภัย Common Criteria ระดับสูงสุด
  • โทเค็นฮาร์ดแวร์ FIDO เป็นวิธีการยืนยันตัวตนที่แข็งแกร่งสำหรับการล็อกอินเข้าสู่เว็บเซอร์วิส และโปรโตคอล FIDO ใช้ ECDSA เป็นองค์ประกอบเข้ารหัสหลัก
  • YubiKey 5 Series เป็นโทเค็นฮาร์ดแวร์ FIDO ที่ใช้งานกันอย่างแพร่หลาย และใช้ Infineon SLE78 เป็น secure element
  • NinjaLab วิเคราะห์การติดตั้งใช้งาน ECDSA ของ Infineon ผ่าน Feitian A22 ซึ่งเป็นแพลตฟอร์ม JavaCard แบบเปิดที่ใช้ Infineon SLE78 ลักษณะคล้ายกัน และออกแบบการโจมตีจริงโดยอาศัยช่องโหว่แบบไซด์แชนเนล
    • การโจมตีถูกสาธิตบน YubiKey 5Ci
    • ช่องโหว่นี้ขยายไปถึง secure microcontroller รุ่นใหม่กว่าอย่าง Infineon Optiga Trust M และ Infineon Optiga TPM ด้วย
  • สาเหตุของช่องโหว่มาจาก modular inverse แบบไม่คงที่ตามเวลา ในไลบรารีเข้ารหัสของ Infineon Technologies และไม่ถูกค้นพบตลอด 14 ปีและการประเมินรับรอง Common Criteria ระดับสูงสุดราว 80 ครั้ง
  • เอกสารทางเทคนิคโดยละเอียดมีให้ที่ Download the Writeup

ผลิตภัณฑ์ที่ได้รับผลกระทบและเงื่อนไขการโจมตี

  • ผู้โจมตีต้อง เข้าถึงทางกายภาพ กับ secure element และสามารถดึงคีย์ลับ ECDSA ออกมาได้ด้วยการวัดไซด์แชนเนลคลื่นแม่เหล็กไฟฟ้าในเครื่องเพียงไม่กี่ครั้ง
    • ในโปรโตคอล FIDO สิ่งนี้ทำให้สามารถ โคลนอุปกรณ์ FIDO ได้
    • การโจมตีต้องใช้อุปกรณ์ราคาแพง ซอฟต์แวร์ปรับแต่งเฉพาะ และทักษะทางเทคนิค
  • ผลิตภัณฑ์ที่ได้รับผลกระทบมีดังนี้
    • เวอร์ชันเดิมทั้งหมดของ Infineon secure microcontroller ทุกตัวที่ฝังไลบรารีเข้ารหัสของ Infineon
    • เวอร์ชันเดิมของ Infineon TPM
    • YubiKey 5 Series ทั้งหมดที่มีเฟิร์มแวร์ต่ำกว่า 5.7
  • secure microcontroller เหล่านี้ถูกใช้อยู่ในระบบความปลอดภัยหลากหลายประเภทที่พึ่งพา ECDSA เช่น หนังสือเดินทางอิเล็กทรอนิกส์ กระเป๋าฮาร์ดแวร์คริปโต Smart Card และสมาร์ตโฮม แต่ยังไม่มีการยืนยันว่า EUCLEAK ใช้งานได้จริงกับผลิตภัณฑ์เหล่านี้หรือไม่
  • Feitian A22 JavaCard เป็นผลิตภัณฑ์รุ่นเก่าที่ใช้ในการวิจัยและไม่มีวางจำหน่ายแล้ว
    • ปัจจุบันผลิตภัณฑ์ที่ใช้ Infineon secure microcontroller และจำหน่ายในเว็บสโตร์ของ Feitian ใช้ไลบรารีเข้ารหัสของ Feitian เอง และเท่าที่ NinjaLab ทราบ ไม่ได้รับผลกระทบจากงานวิจัยนี้

การบรรเทาผลกระทบและข้อมูลอย่างเป็นทางการ

  • YubiKey firmware 5.7 ได้เปลี่ยนจากไลบรารีเข้ารหัสของ Infineon ไปเป็นไลบรารีเข้ารหัสใหม่ของ Yubico ในอัปเดตวันที่ 6 พฤษภาคม 2024
    • เท่าที่ NinjaLab ทราบ ไลบรารีใหม่นี้ไม่ได้รับผลกระทบจาก EUCLEAK
  • Infineon มีแพตช์สำหรับไลบรารีเข้ารหัสอยู่แล้ว แต่เท่าที่ NinjaLab ทราบ ยังไม่ผ่านการประเมินรับรอง Common Criteria
  • คำขอ CVE ถูกปฏิเสธ และ MITRE ใช้ CVE-2024-45678 แทน
    • คำขอให้อัปเดตคำอธิบายยังอยู่ระหว่างรอ
  • จุดยืนอย่างเป็นทางการสามารถดูได้จากเอกสารต่อไปนี้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-04
ความคิดเห็นบน Hacker News

  • อ้างอิงจาก บทความของ Ars Technica ผู้โจมตีต้องมีไม่เพียงชื่อผู้ใช้และรหัสผ่าน แต่ยังต้องมี การเข้าถึงคีย์ทางกายภาพ ด้วย และหากต้องการคืนอุปกรณ์หลังถอดแยกชิ้นส่วน ก็ต้องประกอบกลับเข้าไปใหม่ จึงไม่ใช่การโจมตีเล็ก ๆ น้อย ๆ เลย
    การทายาทาเล็บไว้เล็กน้อยตามรอยต่อพลาสติกน่าจะใช้เป็นคานารีเพื่อบอกได้ว่าถูกงัดแงะหรือไม่
    อย่างไรก็ตาม จุดอ่อนของโทเค็น FIDO ก็ถูกเผยให้เห็นด้วย ต้องจัดการรายชื่อเองว่าเคยลงทะเบียนไว้ที่ไหนบ้าง และหากโทเค็นหายหรือถูกขโมย ก็ต้องไปเพิกถอนเองจากทุกที่ที่ลงทะเบียนไว้

    • นี่ไม่ใช่ปัญหาเฉพาะของ YubiKey
      ตามข้อมูลของ NinjaLab ไมโครคอนโทรลเลอร์ความปลอดภัยของ Infineon ทุกตัวที่รัน ไลบรารีเข้ารหัสของ Infineon มีช่องโหว่ต่อการโจมตีนี้ในทุกเวอร์ชันเดิมที่ทราบ
      ซึ่งรวมถึงชิปหนังสือเดินทางอิเล็กทรอนิกส์ของสหรัฐฯ จีน อินเดีย บราซิล และหลายประเทศในยุโรปและเอเชีย, secure area ในโทรศัพท์ Samsung และ OnePlus, กระเป๋าฮาร์ดแวร์คริปโตอย่าง Ledger และ Trezor, ซิมการ์ด, TPM ในแล็ปท็อป Lenovo, Dell, HP และชิป EMV ในบัตรเครดิต/เดบิต
    • ใช้ KeePassXC เป็น password manager และติดแท็กให้ทุกบัญชีที่ใช้ฮาร์ดแวร์คีย์
      ดังนั้นหากคีย์หาย ถูกขโมย หรือเสีย ก็สามารถดึงรายชื่อเว็บไซต์ที่ต้องถอดออกได้อย่างรวดเร็ว
      ลงทะเบียน คีย์ 2 ตัว ไว้เสมอและเก็บแยกกันทางกายภาพ เพื่อให้แม้ทำหายไปหนึ่งตัวก็ยังล็อกอินได้
    • เห็นด้วยว่าการโจมตีนี้ไม่ใช่เรื่องง่าย แต่บางครั้ง YubiKey ถูกใช้ในสภาพแวดล้อมที่มี ความเสี่ยงสูงมาก
      ไม่ใช่แค่การเข้าถึงสินทรัพย์คริปโต แต่รวมถึงสถานการณ์ที่ร้ายแรงกว่า เช่น บริษัทรับเหมาด้านกลาโหม
      ในกรณีเหล่านี้ ผู้โจมตีมีทั้งทรัพยากรจำนวนมากและแรงจูงใจสูง และก็ใช้ YubiKey เพื่อกันการโจมตีแบบนั้นโดยเฉพาะ
      ดังนั้นคีย์ยังคงให้การยืนยันตัวตนที่ต้านทานฟิชชิงได้ แต่ต้องถือว่าความคาดหวังด้านความปลอดภัยบางส่วนถูกทำลายไปแล้ว
    • หากเป็นผู้โจมตีที่มีทรัพยากรเพียงพอ ก็อาจผลิตคีย์ทดแทนที่ฝัง backdoor พร้อม คีย์ ECDSA เดียวกันได้
    • สำหรับบุคคลทั่วไป คำตอบอาจเป็นการจำกัดให้อุปกรณ์นี้ใช้เฉพาะกับ บริการสำคัญหลัก และที่เหลือพึ่งพาสุขอนามัยด้านรหัสผ่านที่ดี

  • ส่วนที่น่าหงุดหงิดที่สุดคือไม่สามารถเปลี่ยน YubiKey ได้เฉย ๆ
    ไม่ว่าจะใช้ passkey หรือคีย์แบบ non-discoverable ก่อนทิ้งคีย์นี้ต้องไล่เข้าแต่ละบัญชีทีละบัญชีเพื่อเปลี่ยนเป็นคีย์ใหม่ที่ไม่เปราะบาง
    การที่เป็นแบบ non-discoverable ก็เป็นปัญหา เพราะจำไม่ได้ว่าเมื่อก่อนเคยใช้ YubiKey ไว้ที่ไหนบ้าง
    บทความ Ars [0] พูดถึง PIN ด้วย แต่นั่นไม่ใช่ฟีเจอร์เฉพาะของ YubiKey แต่เป็น ฟีเจอร์ของ FIDO
    [0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
    [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

    • อีกมุมหนึ่งคือ เพราะ 2FA ซึ่งเป็นการใช้งานหลักของคีย์ FIDO แบบ non-discoverable จึงกังวลเรื่อง ถูกล็อกออกจากบัญชี มากกว่า
      เคยเจอจริงตอนศุลกากรสหรัฐฯ ยึดอุปกรณ์อิเล็กทรอนิกส์รวมถึง YubiKey ไว้
      ภายหลังสามารถกู้คืนได้หลายบัญชีที่ยอมรับอีเมลเป็น 2FA หรือวิธียืนยันตัวตนสุดท้าย แต่บางบัญชีรวมถึง AWS ทำไม่ได้
      หลายเว็บไซต์แนะนำให้ลงทะเบียน 2FA โดยไม่ได้อธิบายวิธีสำรองสำหรับยืนยันตัวตนและผลของการสูญเสียการเข้าถึงให้ชัดเจน
    • ติดตามไว้ใน password manager
      บัญชีที่ลงทะเบียน YubiKey จะติดแท็ก "YubiKey (FIDO)" ไว้
    • เว็บไซต์ที่ใช้ resident WebAuthn token อย่าง GitHub สามารถแสดงรายชื่อเว็บไซต์ที่รู้จักไว้ในคีย์ได้
      อย่างไรก็ตาม ประสบการณ์ผู้ใช้ ของโฟลว์ทั้งหมดนี้ยังไม่ถึงระดับที่คาดหวัง
    • ไม่ชอบมาตลอดที่ YubiKey ส่วนตัว ไม่สามารถโคลนหรือแบ็กอัปได้ จึงหลีกเลี่ยงการใช้กับทุกที่
    • ยังไม่เคยเห็นเว็บไซต์ที่ไม่บังคับให้ตั้งค่า 2FA รูปแบบอื่นตอนลงทะเบียนอุปกรณ์ FIDO
      ในกรณีของผม จะมี TOTP ที่เก็บไว้ในแอปควบคู่กัน

  • ถ้าบอกว่า “YubiKey 5 Series ทุกตัวที่มีเฟิร์มแวร์ต่ำกว่า 5.7 ได้รับผลกระทบ” ก็นึกว่าแค่อัปเดตเฟิร์มแวร์ของฮาร์ดแวร์โทเค็นก็พอ
    แต่กลับระบุว่า เฟิร์มแวร์ของ YubiKey อัปเกรดไม่ได้
    https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
    ถ้าอย่างนั้น Yubico คงให้เปลี่ยนฟรีใช่ไหม? ผมมี YubiKey แบบนี้อยู่หลายตัว…

    • YubiKey ถูกสร้างมาเพื่อ ป้องกันฟิชชิง และการโจมตีนี้ต้องมีการเข้าถึงทางกายภาพ
      กล่าวคือ หากคุณมีมูลค่าสูงพอที่จะถูกเล็งเป้าโดยตรงในโลกจริง ก็ไม่ควรใช้ YubiKey ตั้งแต่แรก
      อาจมีใครสลับคีย์สำรองของคุณได้ และคุณอาจไม่รู้ตัวจนกว่าจะสายเกินไป
    • ใช้ 5.4.3 5C Nano อยู่ ไม่มีการเปลี่ยนฟรี มีแต่ มาตรการบรรเทา
      https://support.yubico.com/hc/en-us/articles/15705749884444-...
    • ครั้งก่อนที่ชิป Infineon มีบั๊กที่ทำให้รหัสถูกเจาะได้ ประชาชนเอสโตเนียได้รับบัตร ID ใหม่ฟรี
      ในทางกลับกัน YubiKey 4 ของผมที่เพิ่งออกมาไม่ถึงสองเดือนกลับใช้งานเป็น สมาร์ตการ์ด PIV พร้อม hardware attestation ไม่ได้อีกต่อไป

  • ที่บอกว่า “เป็นเพราะการคำนวณ modular inverse ที่ไม่ใช่แบบ constant-time” นั้นไม่ใช่ช่องทางข้างเคียงที่ละเอียดอ่อนอย่างการแผ่คลื่นจิ๋ว ๆ
    การที่เวลาจะเปลี่ยนไปตามข้อมูลลับหรือไม่นั้นแทบจะเป็นหนึ่งในรายการแรก ๆ ที่ต้องตรวจในการ audit ช่องทางข้างเคียง
    แค่ตรวจยืนยันว่าทุกการดำเนินการใช้จำนวน clock cycle เท่ากันเสมอโดยไม่ขึ้นกับข้อมูล และข้อผิดพลาดก็ต้องเกิดหลังจากจำนวน clock cycle คงที่โดยไม่ขึ้นกับข้อมูลเช่นกัน
    สงสัยจริง ๆ ว่าผู้ audit พลาดเรื่องนี้ไปได้อย่างไร

    • ถ้าพูดให้แม่นยำ ดูเหมือนจะใกล้กับ ช่องทางข้างเคียงจากการแผ่คลื่น แบบนั้นมากกว่า
      ถ้าผมเข้าใจงานวิจัยถูกต้อง สิ่งที่ไม่ใช่ constant-time ไม่ใช่ตัวการรันอัลกอริทึมเอง แต่เป็น duty cycle ของช่องทางข้างเคียง RF ที่สังเกตได้จากภายนอก
      ถ้าเวลารันไม่คงที่จริง ๆ กรณีเลวร้ายสุดคงโจมตีผ่าน USB อย่างเดียวได้ด้วย แต่ implementation ของ Infineon ดูเหมือนจะไม่เปราะบางต่อการโจมตีด้วยเวลาอย่างเดียว
      มีการทำ nonce blinding ไว้ด้วย แต่ปัญหาคือใช้ multiplication mask ที่เล็กกว่าขนาดของ elliptic curve มาก ทำให้ brute force ได้
    • เป็นหนึ่งในสิ่งแรก ๆ ที่ต้องตรวจในการรีวิวโค้ด ECDSA ดังนั้นสำหรับ Infineon นี่เป็น ความผิดพลาดที่น่าอาย
    • เห็นด้วย คาดหวังว่าจะเป็นการโจมตีขั้นสูงจริง ๆ แต่กลับใกล้เคียงกับ การโจมตีด้วยเวลามาตรฐาน ที่ติดโพรบเท่ ๆ มากกว่า
      แต่ตัวโพรบเองก็เท่จริง

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

    • สามารถตรวจสอบ ข้อมูลระบุตัวตน ของ YubiKey ได้ด้วย ykman list ดังนั้นจึงวางขั้นตอนตรวจได้ง่าย ๆ ว่ากุญแจเสียจริงหรือถูกสลับ
      ถ้าข้อกำหนดด้านความปลอดภัยสูง ก็ตรวจเป็นระยะหรือปกป้องตำแหน่งทางกายภาพของกุญแจสำรองแยกต่างหากได้
      ก็สงสัยเหมือนกันว่ามี hardware authenticator อะไรที่ปลอดภัยกว่า YubiKey
    • ถ้ามีสิทธิ์เข้าถึงอยู่แล้ว การทำให้กุญแจเสียแล้วสลับกับกุญแจสำรองที่ใช้งานได้เป็นเรื่องง่ายมาก
    • ในทางปฏิบัติ YubiKey คงแทบไม่เคยเป็นจุดอ่อนที่สุดใน chain
      ผู้โจมตีอาจมุ่งโจมตีอุปกรณ์ ดักการสื่อสาร บังคับใช้หมายศาลกับบริการที่โฮสต์ข้อมูล หรือแทรกซึมอย่างลับ ๆ ก็ได้

  • PDF อธิบาย EUCLEAK: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
    บทความบล็อกของ Yubico: https://www.yubico.com/support/security-advisories/ysa-2024-...

  • งานวิจัยของ NinjaLab ยอดเยี่ยมมาก
    ส่วนที่น่าสนใจเป็นพิเศษในคำแนะนำของ Yubico คือการโคลนแบบ local นี้ทำให้ attestation [1] ของโปรโตคอล WebAuthn ใช้ไม่ได้ด้วย
    จะออกแบบโปรโตคอลให้ทนต่อการโจมตีโคลนแบบ local นี้ได้ดีกว่านี้ไหม?
    “ผู้โจมตีสามารถใช้คีย์ attestation ที่กู้คืนมาเพื่อสร้าง YubiKey ปลอมได้ ในกรณีนี้ ระหว่าง make credential จะมีการสร้าง FIDO attestation statement ที่ถูกต้อง ทำให้สามารถข้ามการควบคุม preference ของโมเดล authenticator ขององค์กรสำหรับเวอร์ชัน YubiKey ที่ได้รับผลกระทบได้”

    1. https://www.w3.org/TR/webauthn-2/#attestation
    • ถ้าผู้โจมตีอยู่ในสถานการณ์ที่โคลนค่าลับที่ใช้เซ็นคำขอได้แล้ว เมื่อมีค่าลับนั้นอยู่ ก็ดูเหมือนจะไม่มีวิธีแยกระหว่างสำเนาโคลนกับอุปกรณ์ต้นฉบับ
      โมเดลความปลอดภัยทั้งหมดของ secure element อยู่ที่การป้องกันการสกัดคีย์ และถ้าทำได้แล้วก็แทบไม่ดีกว่าการเก็บคีย์ไว้ในไฟล์คอมพิวเตอร์
      แน่นอนว่าการจะได้คีย์มาต้องเปิดอุปกรณ์ทางกายภาพ ดังนั้นตราบใดที่ไม่มีใครเอากุญแจไปจริง ๆ ก็ยังปลอดภัยกว่าการเก็บไว้ในคอมพิวเตอร์
    • น่าเสียดาย แต่ในทางปฏิบัติทำได้ยาก attestation แทบจะพึ่งพาโครงสร้างที่ฮาร์ดแวร์ปลอดภัยบางอย่างปกป้องความลับที่ผู้ออกให้การรับรองไว้ ใช้มันเพื่อยืนยันตัวเองต่อ relying party แล้วสืบทอดความเชื่อถือด้วยความลับที่ derive และจัดเก็บไว้
      หาก ค่าลับ attestation นั้นถูกสกัดออกมาได้ไม่ว่าด้วยวิธีใด ก็ไม่สามารถป้องกันผู้โจมตีจากการสร้าง authenticator ปลอมที่สร้าง attestation หลอกลวงได้ โดยไม่ต้องทำตัวเหมือนของจริงด้วยซ้ำ
      ในทางทฤษฎีอาจลดผลกระทบจากการรั่วของค่าลับ attestation เดียวได้ด้วยการใช้ indirect attestation หรือคีย์ attestation เฉพาะของแต่ละ authenticator
      เป็นแนวทางแบบนั้นแทนการใช้คีย์ attestation ร่วมกันใน authenticator หลายแสนตัวอย่าง YubiKey แต่ถึงอย่างไรก็น่าจะเป็นได้แค่การบรรเทาเชิงความน่าจะเป็น

  • บนเว็บไซต์ของ Yubico ระบุว่าเวอร์ชัน 5.7 ขึ้นไปไม่ได้รับผลกระทบ
    ถ้าดูบทความอื่นของ Yubico [1] จะเห็นว่าหนึ่งในฟีเจอร์ของรุ่น 5.7 คือการย้ายไปใช้ ไลบรารีเข้ารหัสของ Yubico เอง สำหรับดำเนินการเข้ารหัสพื้นฐานของ RSA และ ECC
    หวังว่าจะมีคนจำนวนมากตรวจดูแล้ว ทุกวันนี้มี implementation ทั้งเปิดเผยและไม่เปิดเผยมากมาย เลยไม่ค่อยเข้าใจว่าทำไมถึงอยากใช้ไลบรารีเข้ารหัสของตัวเอง
    [1] https://www.yubico.com/blog/now-available-for-purchase-yubik...

    • เพราะนี่เป็นครั้งที่สองแล้วที่เกิดปัญหาความปลอดภัยจากซัพพลายเออร์ และครั้งก่อนร้ายแรงกว่านี้
      ถ้าทั้งบริษัทตั้งอยู่บนพื้นฐานของการเข้ารหัส การจ้าง นักเข้ารหัสประยุกต์ ให้เพียงพอและควบคุมชะตากรรมของตัวเองก็สมเหตุสมผลจริง ๆ
    • บนแพลตฟอร์ม embedded ไลบรารีที่มีอยู่อาจยังไม่ถูกพอร์ตมา หรือแพลตฟอร์มอาจแตกต่างเกินกว่าจะพอร์ตได้จริง
      อาจมีเหตุผลอื่นด้วย และในซอฟต์แวร์ปิด ประเด็นเศรษฐศาสตร์ก็มีผลมาก
      โดยเฉพาะถ้าเป็นการย้ายจาก implementation ของซัพพลายเออร์ที่เคยเป็นแบบปิด อาจจะเป็นรูปแบบให้ซอร์ส ไปสู่ implementation ภายในบริษัท ก็ยิ่งเป็นไปได้
    • 5.7 ออกเมื่อไหร่กัน?

  • Infineon เอาอีกแล้ว เมื่อ 7 ปีก่อนก็เคยมีเรื่องแบบนี้: https://en.wikipedia.org/wiki/ROCA_vulnerability

  • มีข้อความว่า “Infineon มีแพตช์สำหรับไลบรารีเข้ารหัสอยู่แล้ว แต่เท่าที่ทราบยังไม่ผ่าน การประเมินรับรอง Common Criteria” แต่พูดตรง ๆ เรื่องนี้ไม่สำคัญเลย

    • หากมองแยกจากตัวการโจมตีเอง ก็เป็นการทดลองที่น่าสนใจและมีคุณค่าในการเปิดเผย แต่ในทางปฏิบัติ แม้แต่อุปกรณ์ที่มีช่องโหว่ในเชิงชื่อเรียก ก็ดูเหมือนจะไม่ได้ส่งผลกระทบต่อโลกจริงมากนัก