Rekomendasi Kriptografi Microsoft SDL

Artikel
02/03/2024

Pendahuluan

Dokumen ini berisi rekomendasi dan praktik terbaik untuk menggunakan enkripsi pada platform Microsoft. Sebagian besar konten di sini diparafrasekan atau diagregasi dari standar keamanan internal Microsoft sendiri yang digunakan untuk membuat Siklus Hidup Pengembangan Keamanan. Ini dimaksudkan untuk digunakan sebagai referensi saat merancang produk untuk menggunakan API, algoritma, protokol, dan panjang kunci yang sama dengan yang diperlukan Microsoft dari produk dan layanannya sendiri.

Pengembang di platform non-Windows juga dapat memperoleh 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 Panjang Kunci Rekomendasi

Versi SSL/TLS

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

TLS 1.2 harus diaktifkan
TLS 1.1 dan TLS 1.0 harus diaktifkan hanya untuk kompatibilitas mundur
SSL 3 dan SSL 2 harus dinonaktifkan secara default

Sandi Blok Simetris, Mode Sandi, dan Vektor Inisialisasi

Blokir Sandi

Untuk produk yang menggunakan cipher blok simetris:

Standar Enkripsi Lanjutan (AES) direkomendasikan untuk kode baru.
Tiga kunci Standar Enkripsi Data tiga kunci (3DES) diizinkan dalam kode yang ada untuk kompatibilitas mundur.
Semua sandi blok lainnya, termasuk RC2, DES, 2-Key 3DES, DESX, dan Skipjack, hanya boleh digunakan untuk mendekripsi data lama, dan harus diganti jika digunakan untuk enkripsi.

Untuk algoritma enkripsi blok simetris, panjang kunci minimum 128 bit disarankan. 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). 3DES tiga kunci saat ini dapat diterima jika sudah digunakan dalam kode yang ada; transisi ke SEL disarankan. DES, DESX, RC2, dan Skipjack tidak lagi dianggap aman. Algoritma ini hanya boleh digunakan untuk mendekripsi data yang ada demi kompatibilitas mundur, dan data harus dienkripsi ulang menggunakan cipher blok yang direkomendasikan.

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 konten harus digunakan dengan salah satu mode sandi berikut:

Rantai Blok Sandi (CBC)
Pencurian Ciphertext (CTS)
Tweaked-Codebook Berbasis XEX dengan Ciphertext Stealing (XTS)

Beberapa mode sandi lain seperti yang disertakan di bawah ini memiliki jebakan 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)
Penghitung dengan CBC-MAC (CCM)
Galois/Mode Penghitung (GCM)
Hal lain yang tidak ada dalam daftar "direkomendasikan" di atas

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. 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, karena ini dapat mengungkapkan informasi tentang data yang dienkripsi, terutama saat menggunakan mode sandi streaming seperti Umpan Balik Output (OFB) atau Penghitung (CTR).

Algoritma Asimetris, Panjang Kunci, dan Mode Padding

RSA

RSA harus 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.
>Kunci = 2048 bit disarankan

ECDSA

ECDSA dengan >= kunci 256 bit disarankan
Tanda tangan berbasis ECDSA harus menggunakan salah satu dari tiga kurva yang disetujui NIST (P-256, P-384, atau P521).

ECDH

ECDH dengan >= kunci 256 bit disarankan
Pertukaran kunci berbasis ECDH harus menggunakan salah satu dari tiga kurva yang disetujui NIST (P-256, P-384, atau P521).

Bilangan bulat Diffie-Hellman

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

Masa Pakai Kunci

Semua kunci asimetris harus memiliki masa pakai lima tahun maksimum, yang direkomendasikan seumur hidup satu tahun.
Semua kunci konten harus memiliki masa pakai maksimum tiga tahun; masa pakai satu tahun yang direkomendasikan.
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 masih dapat 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

Menggunakan BCryptGenRandom dengan bendera BCRYPT_USE_SYSTEM_PREFERRED_RNG

CAPI

Gunakan CryptGenRandom untuk menghasilkan nilai acak.

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, tetapi tidak apa-apa untuk pengujian internal saja.
Fungsi SystemPrng direkomendasikan untuk kode mode kernel.

.NET

Menggunakan RNGCryptoServiceProvider

Aplikasi Bursa Windows

Aplikasi Toko dapat menggunakan CryptographicBuffer.GenerateRandom atau CryptographicBuffer.GenerateRandomNumber.

Tidak direkomendasikan

Fungsi yang tidak aman yang terkait dengan pembuatan angka acak termasuk rand,System.Random (.NET), GetTickCount dan GetTickCount64
Penggunaan algoritma generator angka acak kurva elips ganda ("DUAL_EC_DRBG") tidak disarankan.

Pustaka Kripto yang didukung Platform Windows

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

Setiap keputusan penggunaan mengenai platform vs kripto non-platform 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 Asli

Crypto Primitives: Jika rilis Anda ada di Windows atau Windows Telepon, gunakan CNG jika memungkinkan. Jika tidak, gunakan CryptoAPI (juga disebut CAPI, yang didukung sebagai komponen warisan pada Windows dari Windows Vista dan seterusnya).
SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 , atau IXMLHTTPRequest3.
- Aplikasi WinHTTP harus dibuat dengan WinHttpSetOption untuk mendukung TLS 1.2
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

Crypto Primitives: Gunakan API yang ditentukan dalam namespace System.Security.Cryptography--- kelas CNG lebih disukai.
Gunakan versi terbaru .Net Framework yang tersedia. Minimal ini harus .Net Framework versi 4.6. Jika versi yang lebih lama diperlukan, pastikan regkey "SchUseStrongCrypto" diatur untuk mengaktifkan TLS 1.2 untuk aplikasi yang dimaksud.
Validasi Sertifikat: Gunakan API yang ditentukan di bawah namespace System.Security.Cryptography.X509Certificates.
SSL/TLS/DTLS: Gunakan API yang ditentukan di bawah namespace System.Net (misalnya, HttpWebRequest).

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: Rekomendasi Untuk Derivasi Kunci Menggunakan Fungsi Pseudorandom. Secara khusus, KDF dalam mode penghitung, dengan HMAC sebagai fungsi pseudorandom
NIST SP 800-56A (Revisi 2): Rekomendasi untuk Skema Pembentukan Kunci Bijaksana Pasangan Menggunakan Kriptografi Logaritma Diskrit. Secara khusus, "Fungsi Derivasi Kunci Langkah Tunggal" di Bagian 5.8.1 direkomendasikan.

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 API BCryptDeriveKey dengan salah satu algoritma berikut:

BCRYPT_KDF_SP80056A_CONCAT
BCRYPT_KDF_HMAC

Validasi Sertifikat

Produk yang menggunakan SSL, TLS, atau DTLS harus sepenuhnya memverifikasi sertifikat X.509 entitas yang mereka sambungkan. Ini termasuk verifikasi 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.

Klien yang mempercayai sertifikat "ditandatangani sendiri" (misalnya, klien email yang terhubung ke server Exchange dalam konfigurasi default) dapat mengabaikan pemeriksaan verifikasi sertifikat. Namun, sertifikat yang ditandatangani sendiri tidak secara inheren menyampaikan kepercayaan, pencabutan dukungan, atau pembaruan kunci dukungan. Anda seharusnya hanya mempercayai sertifikat yang ditandatangani sendiri jika Anda telah mendapatkannya dari sumber tepercaya lain (misalnya, entitas tepercaya yang menyediakan sertifikat melalui transportasi yang diautentikasi dan dilindungi integritas).

Fungsi Hash Kriptografi

Produk harus menggunakan keluarga algoritma hash SHA-2 (SHA256, SHA384, dan SHA512). Pemotongan hash kriptografi untuk tujuan keamanan kurang dari 128 bit tidak disarankan.

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).

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 mencapai akhir masa aktifnya atau jika 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. Ini harus mencakup algoritma yang digunakan, ukuran kunci, vektor inisialisasi, dan mode padding.
- Untuk informasi selengkapnya tentang Kelincahan Kriptografi, lihat Kelincahan Kriptografi pada MSDN.
Jika tersedia, produk harus menggunakan protokol kriptografi yang ditetapkan dan disediakan platform daripada menerapkannya kembali. Ini termasuk format penandatanganan (misalnya, gunakan format standar yang ada).
Cipher aliran simetris seperti RC4 tidak boleh digunakan. Alih-alih cipher aliran simetris, produk harus menggunakan cipher blok, khususnya AES dengan panjang kunci setidaknya 128 bit.
Jangan melaporkan 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 tambahan sangat disarankan untuk desain apa pun yang menggabungkan hal-hal berikut:
- Protokol baru yang terutama berfokus pada keamanan (seperti protokol autentikasi atau otorisasi)
- Protokol baru yang menggunakan kriptografi dengan cara baru atau non-standar o Pertimbangan contoh 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 untuk lingkungan produksi. 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 terjadi kegagalan keamanan.

Mengenkripsi Data Sensitif sebelum Penyimpanan

DPAPI/DPAPI-NG

Untuk data yang perlu dipertahankan di seluruh reboot sistem:

CryptProtectData
CryptUnprotectData
NCryptProtectSecret (Windows 8 CNG DPAPI)

Untuk data yang tidak perlu dipertahankan di seluruh reboot sistem:

CryptProtectMemory
CryptUnprotectMemory

Untuk data yang perlu dipertahankan dan diakses oleh beberapa akun domain dan komputer:

NCryptProtectSecret (dalam CNG DPAPI, tersedia pada Windows 8)
Microsoft Azure KeyVault

SQL Server TDE

Anda dapat menggunakan Enkripsi Data Transparan (TDE) SQL Server untuk melindungi data sensitif.

Anda harus menggunakan kunci enkripsi database TDE (DEK) yang memenuhi algoritma kriptografi SDL dan persyaratan kekuatan kunci. Saat ini, hanya AES_128, AES_192, dan AES_256 yang direkomendasikan; TRIPLE_DES_3KEY tidak disarankan.

Ada beberapa pertimbangan penting untuk menggunakan SQL TDE yang harus Anda ingat:

SQL Server tidak mendukung enkripsi untuk data FILESTREAM , bahkan ketika TDE diaktifkan.
TDE tidak secara otomatis menyediakan enkripsi untuk data saat transit ke atau dari database; Anda juga harus mengaktifkan koneksi terenkripsi ke database SQL Server. Silakan lihat MengaktifkanKoneksi terenkripsi ke Mesin Database (Pengelola Konfigurasi SQL Server) untuk panduan tentang mengaktifkan koneksi terenkripsi.
Jika Anda memindahkan database yang dilindungi TDE ke instans SQL Server yang berbeda, Anda juga harus memindahkan sertifikat yang melindungi Kunci Enkripsi Data (DEK) TDE dan menginstalnya di database master instans SQL Server tujuan. Silakan lihat artikel TechNet Memindahkan Database yang Dilindungi TDEke SQL Server Lain untuk detail selengkapnya.

Manajemen Kredensial

Gunakan WINDOWS Credential Manager API atau Microsoft Azure KeyVault untuk melindungi data kata sandi dan kredensial.

Aplikasi Bursa Windows

Gunakan kelas di namespace Windows.Security.Cryptography dan Windows.Security.Cryptography.DataProtection untuk melindungi rahasia dan data sensitif.

ProtectAsync
LindungiStreamAsync
UnprotectAsync
UnprotectStreamAsync

Gunakan kelas di namespace layanan Windows.Security.Credentials untuk melindungi data kata sandi dan kredensial.

.NET