1 poin oleh GN⁺ 2024-09-04 | 1 komentar | Bagikan ke WhatsApp
  • Di tengah penggunaan secure element sebagai fondasi kepercayaan untuk autentikasi yang kuat, EUCLEAK adalah serangan side-channel yang mengekstrak kunci rahasia dari implementasi ECDSA Infineon dan telah didemonstrasikan pada YubiKey 5Ci
  • Kerentanan intinya adalah operasi invers modular non-waktu-konstan dalam pustaka kriptografi Infineon, yang selama 14 tahun telah lolos sekitar 80 evaluasi sertifikasi Common Criteria tingkat tertinggi
  • Penyerang harus memiliki akses fisik ke secure element, dan memerlukan beberapa pengukuran elektromagnetik lokal serta peralatan mahal, perangkat lunak khusus, dan kemampuan teknis, tetapi pengukuran itu sendiri cukup beberapa menit
  • Cakupan dampaknya meliputi YubiKey 5 Series dengan firmware di bawah 5.7 dan secure microcontroller yang menjalankan pustaka kriptografi Infineon, termasuk TPM
  • Dalam FIDO, ekstraksi kunci rahasia ECDSA memungkinkan kloning perangkat, tetapi untuk tujuan pertahanan terhadap phishing, menggunakan produk yang terdampak tetap lebih aman daripada tidak menggunakannya sama sekali

Titik yang dibidik oleh serangan EUCLEAK

  • Secure element adalah mikrocontroller kecil yang membuat dan menyimpan nilai rahasia serta menjalankan operasi kriptografi, dan sering menerima evaluasi keamanan Common Criteria tingkat tertinggi
  • Token hardware FIDO adalah sarana autentikasi kuat yang digunakan untuk login ke layanan web, dan protokol FIDO menggunakan ECDSA sebagai primitive kriptografi intinya
  • YubiKey 5 Series adalah token hardware FIDO yang banyak digunakan dan memakai Infineon SLE78 sebagai secure element
  • NinjaLab menganalisis implementasi ECDSA Infineon menggunakan Feitian A22, platform terbuka JavaCard serupa berbasis Infineon SLE78, lalu merancang serangan nyata yang memanfaatkan kerentanan side-channel
    • Serangan didemonstrasikan pada YubiKey 5Ci
    • Kerentanan juga meluas ke secure microcontroller Infineon Optiga Trust M dan Infineon Optiga TPM yang lebih baru
  • Penyebab kerentanan adalah invers modular non-waktu-konstan dalam pustaka kriptografi Infineon Technologies, dan hal ini tidak ditemukan selama 14 tahun serta sekitar 80 evaluasi sertifikasi Common Criteria tingkat tertinggi
  • Dokumen teknis lengkap tersedia di Download the Writeup

Produk terdampak dan syarat serangan

  • Penyerang harus memiliki akses fisik ke secure element, dan dapat mengekstrak kunci rahasia ECDSA dengan beberapa pengukuran side-channel elektromagnetik lokal
    • Dalam protokol FIDO, ini memungkinkan kloning perangkat FIDO
    • Serangan memerlukan peralatan mahal, perangkat lunak khusus, dan kemampuan teknis
  • Produk yang terdampak adalah sebagai berikut
    • Semua versi lama dari secure microcontroller Infineon yang menyertakan pustaka kriptografi Infineon
    • Versi lama dari Infineon TPM
    • Semua YubiKey 5 Series dengan firmware di bawah 5.7
  • Secure microcontroller tersebut digunakan dalam berbagai sistem keamanan yang bergantung pada ECDSA seperti paspor elektronik, dompet hardware kripto, smart card, dan smart home, tetapi apakah EUCLEAK benar-benar berlaku pada produk-produk tersebut masih belum dikonfirmasi
  • JavaCard Feitian A22 adalah produk lama yang digunakan dalam riset dan sudah tidak lagi dijual
    • Produk berbasis secure microcontroller Infineon yang saat ini dijual di webstore Feitian menggunakan pustaka kriptografi milik Feitian sendiri, dan sejauh yang diketahui NinjaLab, tidak terdampak oleh riset ini

Mitigasi dan informasi resmi

  • Firmware YubiKey 5.7 beralih dari pustaka kriptografi Infineon ke pustaka kriptografi baru milik Yubico dalam pembaruan 6 Mei 2024
    • Sejauh yang diketahui NinjaLab, pustaka baru ini tidak terdampak oleh EUCLEAK
  • Infineon sudah memiliki patch untuk pustaka kriptografinya, tetapi sejauh yang diketahui NinjaLab, patch itu belum lolos evaluasi sertifikasi Common Criteria
  • Permintaan CVE ditolak, dan MITRE sebagai gantinya menggunakan CVE-2024-45678
    • Permintaan pembaruan deskripsi masih menunggu
  • Pernyataan resmi dapat dilihat di dokumen berikut

1 komentar

 
GN⁺ 2024-09-04
Opini Hacker News
  • Berdasarkan artikel Ars Technica, penyerang tidak hanya membutuhkan nama pengguna dan kata sandi, tetapi juga akses fisik ke kunci, dan jika ingin mengembalikannya setelah membongkar perangkat, mereka juga harus merakitnya kembali, jadi ini jelas bukan serangan yang sepele
    Mengoleskan sedikit cat kuku pada sambungan plastik sepertinya bisa dipakai sebagai kanari untuk menunjukkan apakah ada manipulasi
    Namun, ini juga mengungkap kelemahan token FIDO. Kita harus mengelola sendiri daftar tempat token itu didaftarkan, dan jika token hilang atau dicuri, kita harus mencabutnya sendiri di semua tempat yang terdaftar

    • Ini bukan masalah YubiKey saja
      Menurut NinjaLab, semua mikrokontroler keamanan Infineon yang menjalankan pustaka kriptografi Infineon, sejauh diketahui pada semua versi yang ada, rentan terhadap serangan ini
      Ini mencakup chip paspor elektronik AS, Tiongkok, India, Brasil, serta berbagai negara Eropa dan Asia, secure enclave pada ponsel Samsung dan OnePlus, dompet perangkat keras kripto seperti Ledger dan Trezor, kartu SIM, TPM pada laptop Lenovo, Dell, dan HP, serta chip EMV pada kartu kredit dan debit
    • Saya memakai KeePassXC sebagai pengelola kata sandi dan memberi tag pada setiap akun yang memakai hardware key
      Jadi jika kunci hilang, dicuri, atau rusak, saya bisa cepat menarik daftar situs yang perlu dihapus
      Saya selalu mendaftarkan 2 kunci dan menyimpannya terpisah secara fisik, supaya tetap bisa login meskipun salah satunya hilang
    • Saya setuju serangan ini tidak sepele, tetapi YubiKey kadang dipakai di lingkungan dengan tingkat risiko sangat tinggi
      Ini mencakup bukan hanya akses ke aset kripto, tetapi juga situasi yang lebih serius seperti kontraktor pertahanan
      Dalam kasus seperti ini, penyerang punya banyak sumber daya dan motivasi kuat, dan justru untuk mencegah serangan semacam itulah YubiKey digunakan
      Jadi kunci ini masih menyediakan autentikasi yang tahan phishing, tetapi sebagian ekspektasi keamanannya harus dianggap sudah terpatahkan
    • Penyerang dengan sumber daya yang cukup juga bisa membuat kunci pengganti berpintu belakang yang berisi kunci ECDSA yang sama
    • Untuk individu, jawabannya mungkin membatasi penggunaan perangkat ini hanya pada layanan inti, dan untuk sisanya mengandalkan kebersihan kata sandi yang baik
  • Bagian yang paling menjengkelkan adalah YubiKey tidak bisa begitu saja diganti
    Baik memakai passkey maupun kunci non-discoverable, sebelum membuang kunci ini kita harus mendatangi tiap akun satu per satu dan menggantinya dengan kunci baru yang tidak rentan
    Fakta bahwa kuncinya non-discoverable juga jadi masalah, karena saya tidak ingat dulu di mana saja memakai YubiKey
    Artikel Ars [0] juga membahas PIN, tetapi itu bukan fitur khusus YubiKey, melainkan fitur FIDO
    [0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
    [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

    • Dari sisi lain, karena penggunaan utama kunci FIDO non-discoverable adalah autentikasi dua faktor, saya lebih khawatir terkunci dari akun
      Saya pernah benar-benar mengalaminya ketika Bea Cukai AS menahan perangkat elektronik saya, termasuk YubiKey
      Belakangan saya memulihkan banyak akun yang menerima email sebagai autentikasi dua faktor atau sarana autentikasi terakhir, tetapi sebagian, termasuk AWS, tidak begitu
      Banyak situs web mendorong pendaftaran autentikasi dua faktor tanpa menjelaskan dengan jelas sarana autentikasi alternatif dan konsekuensi kehilangan akses
    • Saya melacaknya di pengelola kata sandi
      Untuk akun yang didaftarkan dengan YubiKey, saya memberi tag "YubiKey (FIDO)"
    • Situs yang memakai token WebAuthn resident seperti GitHub bisa menampilkan daftar situs yang diketahui pada kunci
      Namun pengalaman pengguna untuk seluruh alur ini masih belum sesuai harapan
    • Saya selalu tidak suka bahwa YubiKey pribadi tidak bisa dikloning atau dicadangkan, jadi saya menghindari memakainya di semua tempat
    • Saya belum pernah melihat situs yang tidak mewajibkan pengaturan bentuk autentikasi dua faktor lain saat mendaftarkan perangkat FIDO
      Dalam kasus saya, saya juga menyiapkan TOTP yang disimpan di aplikasi
  • Jika “semua YubiKey 5 Series dengan firmware di bawah 5.7 terdampak”, saya kira cukup memperbarui firmware token hardware fisiknya
    Namun ternyata firmware YubiKey tidak bisa di-upgrade
    https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
    Kalau begitu Yubico pasti menyediakan penggantian gratis, kan? Saya punya beberapa YubiKey seperti ini…

    • YubiKey dibuat untuk mencegah phishing, dan serangan ini membutuhkan akses fisik
      Dengan kata lain, jika Anda cukup berharga untuk menjadi target langsung di dunia nyata, sejak awal Anda sebaiknya tidak memakai YubiKey
      Seseorang bisa menukar kunci cadangan Anda, dan Anda mungkin tidak menyadarinya sampai sudah terlambat
    • Saya memakai 5.4.3 5C Nano, tidak ada penggantian gratis, hanya ada mitigasi
      https://support.yubico.com/hc/en-us/articles/15705749884444-...
    • Saat bug pemecah kriptografi pada chip Infineon terjadi sebelumnya, warga Estonia mendapat kartu ID baru secara gratis
      Sebaliknya, YubiKey 4 saya yang baru dirilis kurang dari dua bulan sebelumnya jadi tidak lagi berfungsi sebagai smartcard PIV dengan attestasi hardware
  • “Karena perhitungan invers modular yang tidak berjalan dalam waktu konstan” bukanlah side-channel yang halus seperti emisi elektromagnetik kecil
    Apakah waktu berubah bergantung pada data rahasia adalah salah satu hal pertama yang harus diperiksa dalam audit side-channel
    Cukup verifikasi apakah semua operasi selalu memakai jumlah siklus clock yang sama terlepas dari data, dan error juga harus terjadi setelah jumlah siklus clock yang tetap terlepas dari data
    Saya bertanya-tanya bagaimana auditor bisa melewatkan ini

    • Lebih tepatnya, ini tampaknya lebih dekat ke side-channel elektromagnetik semacam itu
      Jika saya memahami paper-nya dengan benar, yang tidak konstan bukan eksekusi algoritmanya sendiri, melainkan duty cycle side-channel RF yang dapat diamati dari luar
      Kalau waktu eksekusinya benar-benar tidak konstan, dalam skenario terburuk serangan mungkin bisa dilakukan hanya lewat USB, tetapi implementasi Infineon tampaknya tidak rentan terhadap serangan waktu murni
      Nonce blinding juga diimplementasikan, tetapi masalahnya mereka memakai multiplication mask yang jauh lebih kecil daripada ukuran kurva eliptik, sehingga memungkinkan brute force
    • Ini salah satu hal pertama yang diperiksa dalam review kode ECDSA, jadi bagi Infineon ini adalah kesalahan yang memalukan
    • Setuju. Saya mengharapkan serangan yang benar-benar canggih, tetapi ini lebih seperti serangan waktu standar dengan probe keren yang ditempelkan
      Meski begitu, probe-nya sendiri memang keren
  • Kalau sudah sampai mencoba mengakses YubiKey secara fisik, cukup tukar dengan kunci yang sama-sama aus dan tampak mirip
    Dengan begitu korban akan percaya YubiKey-nya rusak, atau penyerang bisa mendapatkan cukup waktu untuk menggunakan YubiKey tersebut
    Misalnya saya punya dua YubiKey, dan jika seseorang diam-diam masuk ke rumah lalu menukar kunci cadangan, saya tidak akan sadar sampai saya memakai kunci cadangan itu
    Pada akhirnya serangan ini hanya masuk akal jika target cukup bernilai untuk disasar langsung, dan target seperti itu mungkin akan memakai sesuatu yang sedikit lebih aman daripada YubiKey

    • Dengan ykman list, informasi identifikasi YubiKey bisa diperiksa, jadi mudah membuat prosedur untuk mengecek apakah kuncinya rusak atau benar-benar ditukar
      Jika kebutuhan keamanannya tinggi, bisa diperiksa berkala atau lokasi fisik kunci cadangan dilindungi secara terpisah
      Saya juga penasaran apa yang lebih aman daripada YubiKey di antara autentikator hardware
    • Kalau punya akses, merusak kunci lalu menukarnya dengan kunci cadangan yang berfungsi itu sangat mudah
    • Dalam praktiknya, YubiKey hampir tidak pernah menjadi mata rantai terlemah
      Penyerang bisa menargetkan perangkat, menyadap komunikasi, menjalankan surat perintah terhadap layanan yang meng-hosting data, atau menyusup secara diam-diam
  • PDF penjelasan EUCLEAK: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
    Tulisan blog Yubico: https://www.yubico.com/support/security-advisories/ysa-2024-...

  • Riset NinjaLab sangat bagus
    Bagian yang terutama menarik dalam advisori Yubico adalah bahwa kloning lokal ini juga melumpuhkan attestation (pembuktian) [1] pada protokol WebAuthn
    Apakah protokolnya bisa dirancang agar lebih tahan terhadap serangan kloning lokal ini?
    “Penyerang dapat menggunakan kunci attestation yang dipulihkan untuk membuat YubiKey palsu. Dalam kasus ini, pernyataan attestation FIDO yang valid dibuat selama make credential, sehingga dapat melewati kontrol preferensi model autentikator organisasi untuk versi YubiKey yang terdampak.”

    1. https://www.w3.org/TR/webauthn-2/#attestation
    • Jika penyerang menyalin nilai rahasia yang dipakai untuk menandatangani permintaan, setelah mereka memiliki rahasia itu tampaknya tidak ada cara untuk membedakan salinan dari perangkat asli
      Seluruh model keamanan secure element bertumpu pada pencegahan ekstraksi kunci; jika itu menjadi mungkin, tidak ada keunggulannya dibanding menyimpan kunci sebagai file komputer
      Tentu saja untuk mendapatkan kunci, perangkat harus dibuka secara fisik, jadi selama tidak ada yang benar-benar mengambil kuncinya, ini tetap lebih aman daripada menyimpannya di komputer
    • Sayangnya, secara realistis ini sulit. Attestation hampir selalu bergantung pada struktur di mana suatu hardware aman menjaga rahasia yang disertifikasi oleh penerbit, mengautentikasi dirinya ke relying party, lalu meneruskan kepercayaan dengan rahasia yang diturunkan dan disimpan
      Jika nilai rahasia attestation itu bisa diekstrak dengan cara apa pun, tidak ada cara untuk mencegah penyerang membuat autentikator palsu yang menghasilkan attestation palsu tanpa perlu bertindak seperti yang asli
      Secara teori, dampak bocornya satu rahasia attestation bisa dikurangi dengan memakai indirect attestation atau kunci attestation unik per autentikator
      Itu berbeda dari pendekatan seperti YubiKey, di mana ratusan ribu autentikator berbagi kunci attestation, tetapi kemungkinan tetap hanya menjadi mitigasi probabilistik
  • Situs web Yubico menyatakan bahwa versi 5.7 ke atas tidak terdampak
    Jika melihat tulisan Yubico lain [1], salah satu fitur rilis 5.7 adalah migrasi ke library kriptografi milik Yubico sendiri untuk melakukan operasi kriptografi dasar RSA dan ECC
    Semoga banyak orang sudah meninjaunya. Di era sekarang yang punya banyak implementasi terbuka maupun tertutup, saya tidak begitu paham mengapa mereka ingin memakai library kriptografi sendiri
    [1] https://www.yubico.com/blog/now-available-for-purchase-yubik...

    • Karena ini kedua kalinya masalah keamanan terjadi akibat pemasok, dan yang sebelumnya lebih parah
      Jika seluruh perusahaan dibangun di atas kriptografi, masuk akal untuk mempekerjakan cukup banyak kriptografer terapan dan mengendalikan nasib sendiri
    • Pada platform embedded, library yang ada mungkin belum di-porting, atau platformnya terlalu berbeda sehingga porting tidak praktis
      Bisa juga ada alasan lain, dan pada source tertutup pertimbangan ekonomi juga besar
      Terutama jika mereka berpindah dari implementasi pemasok yang sebelumnya tertutup, mungkin dalam bentuk source-provided, ke implementasi internal
    • Kapan 5.7 dirilis?
  • Infineon berulah lagi. Hal seperti ini juga terjadi 7 tahun lalu: https://en.wikipedia.org/wiki/ROCA_vulnerability

  • Tertulis bahwa “Infineon sudah memiliki patch untuk pustaka kriptografi, tetapi sejauh yang diketahui, patch itu belum lolos evaluasi sertifikasi Common Criteria”; jujur saja, ini sama sekali tidak penting

    • Terlepas dari serangan itu sendiri, ini eksperimen yang menarik dan layak dipublikasikan, tetapi dalam praktiknya dampaknya di dunia nyata tampaknya tidak besar bahkan pada perangkat yang secara nominal rentan