Bagikan melalui

Rekomendasi kriptografi Microsoft SDL

Gunakan informasi ini sebagai referensi saat merancang produk untuk menggunakan API, algoritma, protokol, dan panjang kunci yang sama dengan yang diperlukan Microsoft dari produk dan layanannya sendiri. Sebagian besar konten didasarkan pada standar keamanan internal Microsoft sendiri yang digunakan untuk membuat Siklus Hidup Pengembangan Keamanan.

Pengembang di platform non-Windows mungkin mendapat manfaat dari rekomendasi ini. Meskipun NAMA API dan pustaka mungkin berbeda, praktik terbaik yang melibatkan pilihan algoritma, panjang kunci, dan perlindungan data serupa di seluruh platform.

Protokol keamanan, algoritma, dan rekomendasi panjang kunci

Versi TLS/SSL

Produk dan layanan harus menggunakan versi TLS/SSL yang aman secara kriptografis:

  • TLS 1.3 harus diaktifkan

  • TLS 1.2 dapat diaktifkan untuk meningkatkan kompatibilitas dengan klien yang lebih lama.

  • TLS 1.1, TLS 1.0, SSL 3, dan SSL 2 harus dinonaktifkan

Cipher blok simetris, mode sandi, dan vektor inisialisasi

Blok cipher

Untuk produk yang menggunakan cipher blok simetris:

  • Standar Enkripsi Tingkat Lanjut (AES) diperlukan.

  • Semua sandi blok lainnya, termasuk 3DES (Triple DES/TDEA), dan RC4 harus diganti jika digunakan untuk enkripsi.

Untuk algoritma enkripsi blok simetris, sebaiknya dukung kunci 256-bit, tetapi izinkan hingga 128-bit. Satu-satunya algoritma enkripsi blok yang direkomendasikan untuk kode baru adalah AES (AES-128, AES-192, dan AES-256 semuanya dapat diterima, mencatat bahwa AES-192 tidak memiliki pengoptimalan pada beberapa prosesor).

Mode Sandi

Algoritma simetris dapat beroperasi dalam berbagai mode, yang sebagian besar menghubungkan operasi enkripsi pada blok teks biasa dan ciphertext berturut-turut.

Cipher blok simetris harus digunakan dengan salah satu mode sandi berikut:

Beberapa mode sandi lain seperti yang mengikuti memiliki perangkap implementasi yang membuatnya lebih mungkin digunakan dengan tidak benar. Secara khusus, mode operasi Buku Kode Elektronik (ECB) harus dihindari. Menggunakan kembali vektor inisialisasi (IV) yang sama dengan cipher blok dalam "mode sandi streaming" seperti CTR dapat menyebabkan data terenkripsi terungkap. Tinjauan keamanan tambahan direkomendasikan jika salah satu mode di bawah ini digunakan:

  • Umpan Balik Output (OFB)

  • Umpan Balik Sandi (CFB)

  • Penghitung (CTR)

  • Hal lain yang tidak ada dalam daftar "direkomendasikan" sebelumnya di atas

Vektor inisialisasi (IV)

Semua cipher blok simetris juga harus digunakan dengan angka acak yang kuat kriptografis sebagai vektor inisialisasi. Vektor inisialisasi tidak boleh menjadi nilai konstanta atau dapat diprediksi. Lihat Generator Angka Acak untuk rekomendasi tentang menghasilkan angka acak yang kuat secara kriptografis.

Vektor inisialisasi tidak boleh digunakan kembali saat melakukan beberapa operasi enkripsi. Penggunaan kembali dapat mengungkapkan informasi tentang data yang dienkripsi, terutama saat menggunakan mode cipher streaming seperti Umpan Balik Output (OFB) atau Penghitung (CTR).

rekomendasi AES-GCM dan AES-CCM

AES-GCM (Galois/Mode Penghitung) dan AES-CCM (Penghitung dengan CBC-MAC) banyak digunakan mode enkripsi terautentikasi. Mereka menggabungkan perlindungan kerahasiaan dan integritas, membuatnya berguna untuk komunikasi yang aman. Namun, kerapuhan mereka terletak pada penggunaan kembali nonce. Ketika nonce yang sama (vektor inisialisasi) digunakan dua kali, hal itu dapat menyebabkan konsekuensi yang sangat merugikan.

Sebaiknya ikuti panduan nonce seperti yang dijelaskan dalam NIST SP 800-38D, Rekomendasi untuk Mode Operasi Cipher Blok: Galois/Mode Penghitung (GCM) dan GMAC, dengan perhatian khusus pada bagian 8.1, 8.2, dan 8.3 mengenai persyaratan keunikan pada kunci dan nonce/IV.

Opsi lain adalah menghasilkan kunci AES-GCM/CCM unik untuk setiap pesan yang dienkripsi, secara efektif membatasi jumlah maksimum pemanggilan menjadi 1. Pendekatan ini direkomendasikan untuk mengenkripsi data yang diam, di mana menggunakan penghitung atau memastikan bahwa Anda dapat melacak jumlah maksimum pemakaian untuk kunci tertentu tidak akan praktis.

Untuk mengenkripsi data tidak aktif, Anda juga dapat mempertimbangkan untuk menggunakan AES-CBC dengan kode autentikasi pesan (MAC) sebagai alternatif menggunakan skema Encrypt-then-MAC, memastikan Anda menggunakan kunci terpisah untuk enkripsi dan untuk MAC.

Verifikasi integritas

Ini adalah kesalahpahaman umum bahwa enkripsi secara default memberikan jaminan kerahasiaan dan integritas. Banyak algoritma enkripsi tidak memberikan pemeriksaan integritas apa pun dan mungkin rentan terhadap serangan yang merusak. Langkah tambahan harus diambil untuk memastikan integritas data sebelum mengirim dan setelah menerima.

Jika Anda tidak dapat menggunakan algoritma enkripsi terautentikasi dengan data terkait (AEAD) seperti AES-GCM, alternatifnya adalah memvalidasi integritas dengan kode autentikasi pesan (MAC) menggunakan skema Encrypt-then-MAC, memastikan Anda menggunakan kunci terpisah untuk enkripsi dan untuk MAC.

Menggunakan kunci terpisah untuk enkripsi dan untuk MAC sangat penting. Jika tidak memungkinkan untuk menyimpan dua kunci, alternatif yang valid adalah mendapatkan dua kunci dari kunci utama menggunakan fungsi derivasi kunci (KDF) yang sesuai, satu untuk tujuan enkripsi dan satu untuk MAC. Untuk informasi selengkapnya, lihat [SP 800-108 Rev. 1, Rekomendasi untuk Derivasi Kunci Menggunakan Fungsi Pseudorandom | CSRC (nist.gov)](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf.

Algoritma asimetris, panjang kunci, dan mode pengisian

RSA

  • RSA dapat digunakan untuk transportasi kunci, pertukaran kunci, dan tanda tangan.

  • Enkripsi RSA harus menggunakan mode OAEP atau RSA-PSS padding.

  • Kode yang ada dapat menggunakan mode padding PKCS #1 v1.5 untuk penandatanganan.

  • Penggunaan PKCS#1 v1.5 untuk enkripsi tidak diperbolehkan.

  • Penggunaan padding null tidak disarankan.

  • Panjang kunci 2048-bit adalah minimum, tetapi sebaiknya dukung panjang kunci 3072-bit.

ECDSA dan ECDH

  • Pertukaran kunci berbasis ECDH dan tanda tangan berbasis ECDSA harus menggunakan salah satu dari tiga kurva yang disetujui NIST (P-256, P-384, atau P521).

  • Dukungan untuk P-256 harus dianggap minimum, tetapi sebaiknya dukung P-384.

ML-DSA

  • Harus menggunakan standar FIPS 204. Jangan gunakan versi dalam draf standar.

  • Disarankan menggunakan ML-DSA dalam kombinasi dengan algoritma tanda tangan klasik (yaitu ECDSA atau RSA). Menggunakan combiner yang ditentukan oleh IETF (draf) atau standar lain lebih disukai untuk interoperabilitas.

  • Untuk ML-DSA, mekanisme hibrida (komposit) yang valid adalah dengan menandatangani data yang sama menggunakan baik metode klasik maupun ML-DSA, dan memverifikasi keduanya (jika salah satu verifikasi gagal, maka verifikasi keseluruhan dianggap gagal).

ML-KEM

  • Harus menggunakan standar FIPS 203. Jangan gunakan versi dalam draf standar.

  • Disarankan menggunakan combiner atau hybrid cryptosystem yang menggabungkan ML-KEM dan algoritma KEM klasik (yaitu ECDH). Menggunakan combiner yang ditentukan oleh IETF (draf) atau standar lain lebih disukai untuk interoperabilitas.

SLH-DSA

  • Harus menggunakan standar FIPS 205. Jangan gunakan versi dalam draf standar.

  • Semua set parameter SLH-DSA diizinkan, tetapi set parameter yang direkomendasikan akan bergantung pada kasus penggunaan.

  • Tidak ada perbedaan keamanan yang diketahui antara versi SHA-2 dan SHAKE (SHA-3)

LMS dan XMSS

  • Aman untuk mendukung LMS atau XMSS untuk verifikasi tanda tangan.

  • Sangat disarankan untuk berkonsultasi dengan pakar subjek sebelum menerapkan/menyebarkan infrastruktur untuk penandatanganan dan pembuatan kunci. Tidak ada kelemahan yang diketahui, tetapi kesalahan yang diinduksi manusia sangat mungkin dan mudah dibuat karena sangat penting untuk mengelola status dengan benar.

Diffie-Hellman bilangan bulat

  • Meskipun Integer Diffie-Hellman (DH) disetujui untuk pertukaran kunci, itu bukan yang paling efisien menurut standar modern. Sangat disarankan untuk menggunakan ECDH sebagai gantinya.
  • Panjang kunci >= 2048 bit disarankan0
  • Parameter grup harus menjadi grup bernama terkenal (misalnya, RFC 7919), atau dihasilkan oleh pihak tepercaya dan diautentikasi sebelum digunakan.

Masa berlaku kunci

  • Tentukan kriptoperiod untuk semua kunci.

    • Misalnya: Kunci simetris untuk enkripsi data, sering disebut sebagai kunci enkripsi data atau DEK, mungkin memiliki periode penggunaan hingga dua tahun untuk mengenkripsi data, juga dikenal sebagai periode penggunaan asal. Anda dapat menentukan bahwa ia memiliki periode penggunaan yang valid untuk dekripsi selama tiga tahun lagi, juga dikenal sebagai periode penggunaan penerima.

  • Anda harus menyediakan mekanisme atau memiliki proses untuk mengganti kunci untuk mencapai masa pakai aktif yang terbatas. Setelah akhir masa aktifnya, kunci tidak boleh digunakan untuk menghasilkan data baru (misalnya, untuk enkripsi atau penandatanganan), tetapi mungkin masih digunakan untuk membaca data (misalnya, untuk dekripsi atau verifikasi).

Generator angka acak

Semua produk dan layanan harus menggunakan generator angka acak yang aman secara kriptografis ketika keacakan diperlukan.

CNG

  • Gunakan BCryptGenRandom dengan bendera BCRYPT_USE_SYSTEM_PREFERRED_RNG.

Win32/64

  • Kode warisan dapat menggunakan RtlGenRandom dalam mode kernel.

  • Kode baru harus menggunakan BCryptGenRandom atau CryptGenRandom.

  • Fungsi C Rand_s() juga direkomendasikan (yang pada Windows, memanggil CryptGenRandom).

  • Rand_s() adalah pengganti yang aman dan berkinerja untuk Rand().

  • Rand() tidak boleh digunakan untuk aplikasi kriptografi apa pun.

.NET

PowerShell

Aplikasi Toko Windows

Pustaka kripto yang didukung platform Windows

Pada platform Windows, Microsoft merekomendasikan penggunaan API kripto yang dibangun ke dalam sistem operasi. Di platform lain, pengembang mungkin memilih untuk mengevaluasi pustaka kripto nonplatform untuk digunakan. Secara umum, pustaka kripto platform diperbarui lebih sering karena dikirim sebagai bagian dari sistem operasi dibandingkan dengan dibundel dengan aplikasi.

Setiap keputusan penggunaan mengenai platform vs kripto nonplatform harus dipandu oleh persyaratan berikut:

  • Pustaka harus menjadi versi terbaru yang didukung dan bebas dari kerentanan keamanan yang sudah dikenal.

  • Protokol keamanan terbaru, algoritma, dan panjang kunci harus didukung.

  • (Opsional) Pustaka harus mampu mendukung protokol/algoritma keamanan yang lebih lama hanya untuk kompatibilitas mundur.

Kode asli

  • Crypto Primitives: Jika rilis Anda ada di Windows, gunakan CNG jika memungkinkan.

  • Verifikasi tanda tangan kode: WinVerifyTrust adalah API yang didukung untuk memverifikasi tanda tangan kode di platform Windows.

  • Validasi Sertifikat (seperti yang digunakan dalam validasi sertifikat terbatas untuk penandatanganan kode atau TLS/DTLS): CAPI2 API; misalnya, CertGetCertificateChain dan CertVerifyCertificateChainPolicy.

Fungsi derivasi utama

Derivasi kunci adalah proses mendapatkan materi kunci kriptografi dari rahasia bersama atau kunci kriptografi yang ada. Produk harus menggunakan fungsi derivasi kunci yang direkomendasikan. Mengambil kunci dari kata sandi yang dipilih pengguna, atau hash kata sandi untuk penyimpanan dalam sistem autentikasi adalah kasus khusus yang tidak tercakup dalam panduan ini; pengembang harus berkonsultasi dengan seorang ahli.

Standar berikut menentukan fungsi KDF yang direkomendasikan untuk digunakan:

  • NIST SP 800-108 (Revisi 1): Rekomendasi Untuk Derivasi Kunci Menggunakan Fungsi Pseudorandom. Secara khusus, KDF dalam mode penghitung, dengan HMAC sebagai fungsi acak semu

  • NIST SP 800-56A (Revisi 3): Rekomendasi untuk Pair-Wise Skema Pembentukan Kunci Menggunakan Kriptografi Logaritma Diskrit.

Untuk mendapatkan kunci dari kunci yang ada, gunakan BCryptKeyDerivation API dengan salah satu algoritma:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Untuk mendapatkan kunci dari rahasia bersama (output perjanjian kunci), gunakan BCryptDeriveKey API dengan salah satu algoritma berikut:

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

Validasi sertifikat

Produk yang menggunakan TLS, atau DTLS harus sepenuhnya memverifikasi sertifikat X.509 entitas yang mereka sambungkan. Proses ini mencakup verifikasi bagian-bagian berikut dari sertifikat:

  • Nama domain.

  • Tanggal validitas (tanggal mulai dan kedaluwarsa).

  • Status pencabutan.

  • Penggunaan (misalnya, "Autentikasi Server" untuk server, "Autentikasi Klien" untuk klien).

  • Rantai kepercayaan. Sertifikat harus dirantai ke otoritas sertifikasi akar (CA) yang dipercaya oleh platform atau dikonfigurasi secara eksplisit oleh administrator.

Jika salah satu pengujian verifikasi ini gagal, produk harus mengakhiri koneksi dengan entitas.

Jangan gunakan sertifikat "ditandatangani sendiri". Tanda tangan sendiri tidak secara inheren menyampaikan kepercayaan, mendukung pencabutan, atau mendukung pembaruan kunci.

Fungsi hash kriptografi

Produk harus menggunakan keluarga algoritma hash SHA-2 (SHA-256, SHA-384, dan SHA-512). Pemotongan hash kriptografi untuk tujuan keamanan hingga kurang dari 128 bit tidak diizinkan. Meskipun penggunaan SHA-256 adalah minimum, sebaiknya dukung SHA-384.

Algoritma hash MAC/HMAC/berkunci

Kode autentikasi pesan (MAC) adalah bagian dari informasi yang dilampirkan ke pesan yang memungkinkan penerimanya memverifikasi keaslian pengirim dan integritas pesan menggunakan kunci rahasia.

Direkomendasikan untuk menggunakan MAC berbasis hash (HMAC) atau MAC berbasis sandi blok selama semua algoritma hash atau enkripsi simetris yang mendasarinya juga direkomendasikan untuk digunakan; saat ini termasuk fungsi HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384, dan HMAC-SHA512). Meskipun penggunaan HMAC-SHA256 adalah minimum, sebaiknya dukung HMAC-SHA384.

Pemotongan HMAC menjadi kurang dari 128 bit tidak disarankan.

Pertimbangan desain dan operasional

  • Anda harus menyediakan mekanisme untuk mengganti kunci kriptografi sesuai kebutuhan. Kunci harus diganti setelah mereka mencapai akhir masa aktif mereka atau kunci kriptografi disusupi.

    • Setiap kali Anda memperbarui sertifikat, Anda harus memperbaruinya dengan kunci baru (pembuatan ulang kunci).

  • Produk yang menggunakan algoritma kriptografi untuk melindungi data harus menyertakan metadata yang cukup bersama dengan konten tersebut untuk mendukung migrasi ke algoritma yang berbeda di masa mendatang. Metadata ini harus mencakup algoritma yang digunakan, ukuran kunci, dan mode padding.

  • Jika tersedia, produk harus menggunakan protokol kriptografi yang ditetapkan dan disediakan platform daripada melengkapinya kembali, termasuk format penandatanganan (misalnya, menggunakan format standar yang ada).

  • Jangan laporkan kegagalan operasi kriptografi kepada pengguna akhir. Saat mengembalikan kesalahan ke pemanggil jarak jauh (misalnya, klien web, atau klien dalam skenario server klien), gunakan pesan kesalahan umum saja.

    • Hindari memberikan informasi yang tidak perlu, seperti secara langsung melaporkan kesalahan di luar jangkauan atau panjang yang tidak valid. Catat kesalahan secara rinci pada server saja, dan hanya jika pencatatan rinci diaktifkan.

  • Tinjauan keamanan ekstra sangat disarankan untuk desain apa pun yang menggabungkan item berikut:

    • Protokol baru yang terutama berfokus pada keamanan (seperti protokol autentikasi atau otorisasi)

    • Protokol baru yang menggunakan kriptografi dengan cara yang baru atau tidak biasa. Contoh pertimbangan meliputi:

      • Apakah produk yang mengimplementasikan protokol memanggil API atau metode kripto apa pun sebagai bagian dari implementasi protokol?

      • Apakah protokol bergantung pada protokol lain yang digunakan untuk autentikasi atau otorisasi?

      • Apakah protokol akan menentukan format penyimpanan untuk elemen kriptografi, seperti kunci?

  • Sertifikat yang ditandatangani sendiri tidak disarankan. Penggunaan sertifikat yang ditandatangani sendiri, seperti penggunaan kunci kriptografi mentah, tidak secara inheren memberikan dasar apa pun kepada pengguna atau administrator untuk membuat keputusan kepercayaan.

    • Sebaliknya, penggunaan sertifikat yang berakar pada otoritas sertifikat tepercaya menjelaskan dasar untuk mengandalkan kunci privat terkait dan memungkinkan pencabutan dan pembaruan jika ada kegagalan keamanan.
  • Last updated on