Bagikan melalui

Perubahan pemecahan kriptografi untuk .NET Core 2.1-3.0

Perubahan mencolok berikut ini didokumenkan di halaman ini:

Perubahan yang memutus kompatibilitas Versi yang diperkenalkan
MULAI sintaks SERTIFIKAT TEPERCAYA tidak lagi didukung di Linux 3.0
EnvelopedCms default ke enkripsi AES-256 3.0
Ukuran minimum untuk pembuatan kunci RSAOpenSsl telah meningkat 3.0
.NET Core 3.0 lebih suka OpenSSL 1.1.x ke OpenSSL 1.0.x 3.0
CryptoStream.Dispose mengubah blok akhir hanya saat menulis 3.0
parameter Boolean dari SignedCms.ComputeSignature dihormati 2.1

.NET Core 3.0

Sintaks "BEGIN TRUSTED CERTIFICATE" tidak lagi didukung untuk sertifikat akar di Linux

Sertifikat akar di Linux dan sistem seperti Unix lainnya (tetapi tidak macOS) dapat disajikan dalam dua bentuk: header PEM standar BEGIN CERTIFICATE , dan header PEM khusus BEGIN TRUSTED CERTIFICATE OpenSSL. Sintaks terakhir memungkinkan konfigurasi tambahan yang telah menyebabkan masalah kompatibilitas dengan kelas .NET Core System.Security.Cryptography.X509Certificates.X509Chain . BEGIN TRUSTED CERTIFICATE konten sertifikat akar tidak lagi dimuat oleh mesin rantai yang dimulai di .NET Core 3.0.

Ubah deskripsi

Sebelumnya, sintaks BEGIN CERTIFICATE dan BEGIN TRUSTED CERTIFICATE digunakan untuk mengisi daftar kepercayaan akar. BEGIN TRUSTED CERTIFICATE Jika sintaks digunakan dan opsi tambahan ditentukan dalam file, X509Chain mungkin telah melaporkan bahwa kepercayaan rantai secara eksplisit tidak diizinkan (X509ChainStatusFlags.ExplicitDistrust). Namun, jika sertifikat juga ditentukan dengan BEGIN CERTIFICATE sintaks dalam file yang dimuat sebelumnya, kepercayaan rantai diizinkan.

Mulai dari .NET Core 3.0, BEGIN TRUSTED CERTIFICATE konten tidak lagi dibaca. Jika sertifikat tidak juga ditentukan melalui sintaks standar BEGIN CERTIFICATE , X509Chain laporan bahwa akar tidak tepercaya (X509ChainStatusFlags.UntrustedRoot).

Versi yang diperkenalkan

3.0

Sebagian besar aplikasi tidak terpengaruh oleh perubahan ini, tetapi aplikasi yang tidak dapat melihat kedua sumber sertifikat akar karena masalah izin mungkin mengalami kesalahan yang tidak terduga UntrustedRoot setelah peningkatan.

Banyak distribusi Linux (atau distro) menulis sertifikat akar ke dua lokasi: direktori satu sertifikat per file, dan perangkaian satu file. Pada beberapa distro, direktori satu-sertifikat-per-file menggunakan BEGIN TRUSTED CERTIFICATE sintaks sementara perangkaian file menggunakan sintaks standar BEGIN CERTIFICATE . Pastikan bahwa sertifikat akar kustom ditambahkan seperti BEGIN CERTIFICATE di setidaknya salah satu lokasi ini, dan kedua lokasi dapat dibaca oleh aplikasi Anda.

Direktori yang khas adalah /etc/ssl/certs/ dan file yang digabungkan yang khas adalah /etc/ssl/cert.pem. Gunakan perintah openssl version -d untuk menentukan root khusus platform, yang mungkin berbeda dari /etc/ssl/. Misalnya, pada Ubuntu 18.04, direktorinya adalah /usr/lib/ssl/certs/ dan filenya adalah /usr/lib/ssl/cert.pem. Namun, /usr/lib/ssl/certs/ adalah symlink ke /etc/ssl/certs/ dan /usr/lib/ssl/cert.pem tidak ada.

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
$ ls -al /usr/lib/ssl
total 12
drwxr-xr-x  3 root root 4096 Dec 12 17:10 .
drwxr-xr-x 73 root root 4096 Feb 20 15:18 ..
lrwxrwxrwx  1 root root   14 Mar 27  2018 certs -> /etc/ssl/certs
drwxr-xr-x  2 root root 4096 Dec 12 17:10 misc
lrwxrwxrwx  1 root root   20 Nov 12 16:58 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx  1 root root   16 Mar 27  2018 private -> /etc/ssl/private

Kategori

Kriptografi

API yang terpengaruh

EnvelopedCms default ke enkripsi AES-256

Algoritma enkripsi simetris default yang digunakan oleh EnvelopedCms telah berubah dari TripleDES menjadi AES-256.

Ubah deskripsi

Dalam versi sebelumnya, ketika EnvelopedCms digunakan untuk mengenkripsi data tanpa menentukan algoritma enkripsi simetris melalui kelebihan beban konstruktor, data dienkripsi dengan algoritma TripleDES/3DES/3DEA/DES3-EDE.

Dimulai dengan .NET Core 3.0 (melalui versi 4.6.0 dari paket NuGet System.Security.Cryptography.Pkcs ), algoritma default telah diubah ke AES-256 untuk modernisasi algoritma dan untuk meningkatkan keamanan opsi default. Jika sertifikat penerima pesan memiliki kunci umum Diffie-Hellman (non-EC), operasi enkripsi mungkin gagal karena CryptographicException keterbatasan di platform yang mendasar.

Dalam kode sampel berikut, data dienkripsi dengan TripleDES jika berjalan pada .NET Core 2.2 atau yang lebih lama. Jika berjalan pada .NET Core 3.0 atau yang lebih baru, itu dienkripsi dengan AES-256.

EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();

Versi yang diperkenalkan

3.0

Jika Anda terkena dampak negatif dari perubahan tersebut, Anda dapat memulihkan enkripsi TripleDES dengan secara eksplisit menentukan pengidentifikasi algoritma enkripsi dalam EnvelopedCms konstruktor yang menyertakan parameter jenis AlgorithmIdentifier, seperti:

Oid tripleDesOid = new Oid("1.2.840.113549.3.7", null);
AlgorithmIdentifier tripleDesIdentifier = new AlgorithmIdentifier(tripleDesOid);
EnvelopedCms cms = new EnvelopedCms(content, tripleDesIdentifier);

cms.Encrypt(recipient);
return cms.Encode();

Kategori

Kriptografi

API yang terpengaruh

Ukuran minimum untuk pembuatan kunci RSAOpenSsl telah meningkat

Ukuran minimum untuk menghasilkan kunci RSA baru di Linux telah meningkat dari 384-bit menjadi 512-bit.

Ubah deskripsi

Dimulai dengan .NET Core 3.0, ukuran kunci hukum minimum yang dilaporkan oleh LegalKeySizes properti pada instans RSA dari RSA.Create, RSAOpenSsl, dan RSACryptoServiceProvider di Linux telah meningkat dari 384 menjadi 512.

Akibatnya, dalam .NET Core 2.2 dan versi yang lebih lama, panggilan metode seperti RSA.Create(384) berhasil. Di .NET Core 3.0 dan versi yang lebih baru, panggilan RSA.Create(384) metode melempar pengecualian yang menunjukkan ukurannya terlalu kecil.

Perubahan ini dilakukan karena OpenSSL, yang melakukan operasi kriptografi di Linux, meningkatkan minimumnya antara versi 1.0.2 dan 1.1.0. .NET Core 3.0 lebih memilih OpenSSL 1.1.x hingga 1.0.x, dan versi minimum yang dilaporkan dinaikkan untuk mencerminkan batasan dependensi baru yang lebih tinggi ini.

Versi yang diperkenalkan

3.0

Jika Anda memanggil salah satu API yang terpengaruh, pastikan bahwa ukuran kunci yang dihasilkan tidak kurang dari minimum penyedia.

Nota

RSA 384-bit sudah dianggap tidak aman (seperti RSA 512-bit). Rekomendasi modern, seperti Publikasi Khusus NIST 800-57 Bagian 1 Revisi 4, menyarankan 2048-bit sebagai ukuran minimum untuk kunci yang baru dihasilkan.

Kategori

Kriptografi

API yang terpengaruh

.NET Core 3.0 lebih suka OpenSSL 1.1.x ke OpenSSL 1.0.x

.NET Core untuk Linux, yang berfungsi di beberapa distribusi Linux, dapat mendukung OpenSSL 1.0.x dan OpenSSL 1.1.x. .NET Core 2.1 dan .NET Core 2.2 mencari 1.0.x terlebih dahulu, lalu kembali ke 1.1.x; .NET Core 3.0 mencari 1.1.x terlebih dahulu. Perubahan ini dilakukan untuk menambahkan dukungan untuk standar kriptografi baru.

Perubahan ini dapat memengaruhi pustaka atau aplikasi yang melakukan interop platform dengan jenis interop khusus OpenSSL di .NET Core.

Ubah deskripsi

Di .NET Core 2.2 dan versi yang lebih lama, runtime lebih suka memuat OpenSSL 1.0.x lebih dari 1.1.x. Ini berarti bahwa IntPtr jenis dan SafeHandle untuk interop dengan OpenSSL digunakan dengan libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 berdasarkan preferensi.

Dimulai dengan .NET Core 3.0, runtime lebih suka memuat OpenSSL 1.1.x daripada OpenSSL 1.0.x, sehingga IntPtr jenis dan SafeHandle untuk interop dengan OpenSSL digunakan dengan libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1 berdasarkan preferensi. Akibatnya, pustaka dan aplikasi yang beroperasi dengan OpenSSL secara langsung mungkin memiliki pointer yang tidak kompatibel dengan nilai .NET Core-exposed saat meningkatkan dari .NET Core 2.1 atau .NET Core 2.2.

Versi yang diperkenalkan

3.0

Pustaka dan aplikasi yang melakukan operasi langsung dengan OpenSSL perlu berhati-hati untuk memastikan mereka menggunakan versi OpenSSL yang sama dengan runtime .NET Core.

Semua pustaka atau aplikasi yang menggunakan IntPtr atau SafeHandle nilai dari jenis kriptografi .NET Core secara langsung dengan OpenSSL harus membandingkan versi pustaka yang mereka gunakan dengan properti baru SafeEvpPKeyHandle.OpenSslVersion untuk memastikan pointer kompatibel.

Kategori

Kriptografi

API yang terpengaruh

CryptoStream.Dispose mengubah blok akhir hanya saat menulis

Metode CryptoStream.Dispose ini, yang digunakan untuk menyelesaikan CryptoStream operasi, tidak lagi mencoba mengubah blok akhir saat membaca.

Ubah deskripsi

Dalam versi .NET sebelumnya, jika pengguna melakukan pembacaan yang tidak lengkap saat menggunakan CryptoStream dalam Read mode, Dispose metode dapat melemparkan pengecualian (misalnya, saat menggunakan AES dengan padding). Pengecualian dilemparkan karena blok akhir dicoba untuk diubah tetapi data tidak lengkap.

Di .NET Core 3.0 dan versi yang lebih baru, Dispose tidak lagi mencoba mengubah blok akhir saat membaca, yang memungkinkan pembacaan yang tidak lengkap.

Alasan perubahan

Perubahan ini memungkinkan pembacaan yang tidak lengkap dari aliran kripto ketika operasi jaringan dibatalkan, tanpa perlu menangkap pengecualian.

Versi yang diperkenalkan

3.0

Sebagian besar aplikasi tidak boleh terpengaruh oleh perubahan ini.

Jika aplikasi Anda sebelumnya menangkap pengecualian jika pembacaan tidak lengkap, Anda dapat menghapus blok tersebut catch . Jika aplikasi Anda menggunakan transformasi blok akhir dalam skenario hashing, Anda mungkin perlu memastikan bahwa seluruh aliran dibaca sebelum dibuang.

Kategori

Kriptografi

API yang terpengaruh

.NET Core 2.1

Parameter Boolean dari SignedCms.ComputeSignature diperhatikan

Di .NET Core, parameter silent Boolean dari metode SignedCms.ComputeSignature(CmsSigner, Boolean) dihormati. Perintah PIN tidak ditampilkan jika parameter ini diatur ke true.

Ubah deskripsi

Dalam .NET Framework, parameter silent metode SignedCms.ComputeSignature(CmsSigner, Boolean) diabaikan, dan perintah PIN selalu ditampilkan jika diperlukan oleh penyedia. Di .NET Core, parameter silent dihormati, dan jika diatur ke true, perintah PIN tidak pernah ditampilkan, bahkan jika diperlukan oleh penyedia.

Dukungan untuk pesan CMS/PKCS #7 diperkenalkan ke .NET Core dalam versi 2.1.

Versi yang diperkenalkan

2.1

Untuk memastikan perintah PIN muncul jika diperlukan, aplikasi desktop harus memanggil SignedCms.ComputeSignature(CmsSigner, Boolean) dan mengatur parameter Boolean ke false. Perilaku yang dihasilkan sama seperti pada .NET Framework terlepas dari apakah konteks senyap dinonaktifkan di sana.

Kategori

Kriptografi

API yang terpengaruh