Bagikan melalui

Rekomendasi kriptografi Microsoft SDL

  • Artikel

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

Blokir cipher

Untuk produk yang menggunakan cipher blok simetris:

  • Standar Enkripsi Tingkat Lanjut (AES) disarankan.
  • Semua sandi blok lainnya, termasuk 3DES (Triple DES/TDEA), dan RC4 harus diganti jika digunakan untuk enkripsi.

Untuk algoritma enkripsi blok simetris, panjang kunci minimum 128 bit diperlukan, tetapi sebaiknya dukung kunci 256-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 cipher

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

Cipher blok konten 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

Vektor inisialisasi (IV)

Semua cipher blok konten juga harus digunakan dengan angka acak yang kuat secara 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 & AES-CCM

AES-GCM (Mode Galois/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, itu dapat menyebabkan konsekuensi bencana.

Sebaiknya ikuti panduan nonce seperti yang dijelaskan dalam NIST SP 800-38D, Rekomendasi untuk Mode Operasi Cipher Blok: Galois/Mode Penghitung (GCM) dan GMAC, memperhatikan secara khusus bagian 8.3 mengenai jumlah maksimum pemanggilan.

Opsi lain akan dihasilkan kunci AES-GCM/CCM unik untuk setiap pesan yang dienkripsi, secara efektif membatasi jumlah maksimum pemanggilan menjadi 1. Pendekatan ini direkomendasikan untuk mengenkripsi data tidak aktif, di mana menggunakan penghitung atau memastikan bahwa Anda dapat melacak jumlah maksimum pemanggilan 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).

Algoritma asimetris, panjang kunci, dan mode padding

RSA

  • RSA dapat digunakan untuk enkripsi, pertukaran kunci, dan tanda tangan.
  • Enkripsi RSA harus menggunakan mode padding OAEP atau RSA-PSS.
  • Kode yang ada harus menggunakan mode padding PKCS #1 v1.5 untuk kompatibilitas saja.
  • Penggunaan padding null tidak disarankan.
  • Minimal panjang kunci 2048-bit disarankan, 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.

Bilangan bulat Diffie-Hellman

  • Panjang kunci >= 2048 bit direkomendasikan0
  • Parameter grup harus menjadi grup bernama terkenal (misalnya, RFC 7919), atau dihasilkan oleh pihak tepercaya dan diautentikasi sebelum digunakan.

Masa pakai 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

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 Windows Store

Linux/macOS

  • Perangkat ini /dev/urandom menyediakan sumber data acak yang kuat secara kriptografis, seperti halnya getrandom(2) panggilan sistem.

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 dalam dukungan saat ini yang bebas dari kerentanan keamanan yang diketahui.
  • 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 native

  • 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 SSL/TLS/DTLS): CAPI2 API; misalnya, CertGetCertificateChain dan CertVerifyCertificateChainPolicy.

Kode terkelola (.NET)

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 pseudorandom
  • NIST SP 800-56A (Revisi 3): Rekomendasi untuk Skema Pembentukan Kunci Bijaksana Pasangan 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

Certificate validation

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". Ditandatangani sendiri tidak secara inheren menyampaikan kepercayaan, pencabutan dukungan, atau pembaruan kunci dukungan.

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/keyed

Kode autentikasi pesan (MAC) adalah sepotong informasi yang dilampirkan pada pesan yang memungkinkan penerimanya untuk memverifikasi keaslian pengirim dan integritas pesan menggunakan kunci rahasia.

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

Pemotongan HMAC hingga 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 Memperpanjang sertifikat, Anda harus memperbaruinya dengan kunci baru.
  • 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.
    • Untuk informasi selengkapnya tentang Kelincahan Kriptografi, lihat artikel Kelincahan Kriptografi.
  • 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 melaporkan kesalahan di luar jangkauan atau panjang yang tidak valid secara langsung. Mencatat kesalahan verbose pada server saja, dan hanya jika pengelogan verbose 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.