Di Amerika Serikat, GOST juga biasa-biasa saja. YubiKey FIPS kerentanan fatal yang bisa dihindari

Hai% nama pengguna%!

Pada 13 Juni 2019, Yubico, produsen perangkat otentikasi dua faktor, mengeluarkan pemberitahuan keamanan yang menyatakan kerentanan kritis beberapa perangkat Yubikey FIPS. Mari kita lihat apa kerentanan ini dan bagaimana itu bisa dicegah.

Kata Pengantar

Amerika juga memiliki GOST mereka sendiri, yang disebut FIPS - Federal Information Processing Standard. Perangkat keras dan perangkat lunak yang dengannya negara. struktur yang diperlukan untuk mematuhi FIPS.

Menurut kolega yang kami temui di EuroCrypt 2019, sertifikasi FIPS adalah hal yang luar biasa, sampai-sampai ahli FIPS datang kepada Anda, meluncurkan perangkat lunak Anda dalam mode debug, mengubah nilai-nilai dalam memori dan memeriksa apakah itu jatuh di tempat yang dimaksudkan.

Meskipun demikian, mendapatkan sertifikasi dan menjadi patuh FIPS adalah nyata. Oleh karena itu, produk dan perusahaan yang memberikan layanan kepada negara, ada berkali-kali lebih banyak dari kita.

ECDSA

Di dalam token usb Yubico ada penyimpanan untuk kunci dan mesin yang mengimplementasikan termasuk ECDSA. Selama pendaftaran, kunci publik dari token ditransfer ke server dan disimpan.

Dan saat login, server mengirimkan string acak ke klien, yang ditandatangani bersama dengan meta-informasi, seperti, misalnya, domain.

Singkatnya tentang bagaimana ECDSA atau tanda tangan digital pada kurva eliptik bekerja. Beberapa detail dihilangkan untuk kemudahan presentasi:

1. Kami mempertimbangkan hash dari pesan dan menerjemahkannya ke dalam angka. $$$e = HASH (m)$.
2. Kami menghasilkan angka acak kriptografis yang kuat k.
3. Hitung titik $$$(x, y) = k * G$di mana G adalah titik dasar dari kurva yang disebut generator (konstan)
4. Kami menghitung $$$r = x ~ mod ~ n$di mana n adalah urutan titik dasar (konstan)
5. Kami menghitung $$$s = k ^ {- 1} (e + r * d) \, \ bmod \, n$di mana d adalah kunci pribadi
6. Tanda tangan digital terdiri dari sepasang angka r, s

Sangat penting bahwa angka k tidak hanya rahasia, tetapi selalu berbeda. Jika tidak, menjadi mungkin untuk menghitung kunci pribadi.

Sebagai contoh, kami memiliki dua tanda tangan (r, s) dan (r1, s1), yang diterima untuk pesan yang berbeda m dan m1, tetapi menggunakan rahasia yang sama k. Mari kita hitung kunci pribadi.

• Penyerang menghitung e dan e1.
• Sejak $$$s - s1 = k ^ {- 1} (e - e1)$maka kita bisa mencari tahu k. $$$k = \ frac {e - e1} {s - s1}$
• Sejak $$$s = k ^ {- 1} (e + r * d)$, maka kita bisa menghitung d. $$$d = \ frac {s * k - e} {r}$
• d - kunci pribadi

Jika angka k berbeda, tetapi tidak cukup , maka Anda juga dapat menghitung kunci pribadi, Anda hanya perlu sedikit memaksa. Ngomong-ngomong, pada tahun 2013, saya sudah menulis bagaimana DSA diterapkan dengan canggung di PlayStation dan produk lainnya, saya sangat merekomendasikan untuk membacanya.

Yubico

Jadi, di sejumlah produk Yubico FIPS ada bug di mana angka k segera setelah menyalakan token tidak sepenuhnya acak. Dan ada peluang nyata untuk menghitung kunci privat yang terhubung. Karena itu, mereka menarik kembali perangkat yang rentan dan mengeluarkan pemberitahuan.

Apa yang bisa dilakukan?

Secara umum, masalahnya sudah lama terselesaikan. Sejak 2013, ada RFC 6979 , yang menggambarkan ECDSA deterministik yang diperoleh dari yang biasa melalui beberapa modifikasi sederhana. Selain itu, pada tahun 2014, ketika mengembangkan standar U2F, justru karena potensi masalah dengan RPS yang FIPS secara terbuka mengusulkan untuk beralih ke Deterministic ECDSA, tetapi tawaran itu ditolak. Ini adalah salah satu alasan FIPS singkatan dari F * cked-up, Insecure, Persnickety Standards.

Yubico secara formal dapat memenuhi persyaratan FIPS untuk keacakan angka k, tetapi menggunakan solusi, menghasilkan k secara deterministik, dan kemudian XOR dengan fakta bahwa ia mengeluarkan RNG (atau dengan menjalankan semuanya melalui KDF). Namun, ini belum dilakukan.

Bagaimana dengan kita?

Dan kami memiliki hal yang sama. GOST R 34.10-2012 - pada dasarnya ECDSA yang sama, hanya dengan kurva yang berbeda. Persyaratan untuk menghasilkan angka k tetap sama seperti pada ECDSA tradisional. Apakah ada dari produsen token kami yang melakukan solusi yang dijelaskan di atas? Apakah ia menggunakan versi deterministik dari ECDSA? Saya meragukannya.

Jika ada perwakilan dari pengembang Rusia, akan menarik untuk mendengarkan pendapat mereka tentang masalah ini. Atau setidaknya untuk mengingatnya.

Terima kasih atas perhatian anda