Microsoft SDL şifreleme önerileri

  • Makale

Bu bilgileri, Microsoft'un kendi ürün ve hizmetleri için gerektirdiği API'leri, algoritmaları, protokolleri ve anahtar uzunluklarını kullanacak şekilde ürün tasarlarken başvuru olarak kullanın. İçeriğin büyük bir kısmı, Microsoft'un Güvenlik Geliştirme Yaşam Döngüsü oluşturmak için kullanılan kendi iç güvenlik standartlarını temel alır.

Windows olmayan platformlardaki geliştiriciler bu önerilerden yararlanabilir. API ve kitaplık adları farklı olsa da algoritma seçimi, anahtar uzunluğu ve veri koruması gibi en iyi yöntemler platformlar arasında benzerdir.

Güvenlik protokolü, algoritma ve anahtar uzunluğu önerileri

TLS/SSL sürümleri

Ürün ve hizmetler TLS/SSL'nin şifreleme açısından güvenli sürümlerini kullanmalıdır:

  • TLS 1.3 etkinleştirilmelidir.
  • TLS 1.2, eski istemcilerle uyumluluğu geliştirmek için etkinleştirilebilir.
  • TLS 1.1, TLS 1.0, SSL 3 ve SSL 2 devre dışı bırakılmalıdır

Simetrik blok şifrelemeleri, şifreleme modları ve başlatma vektörleri

Şifrelemeleri engelleme

Simetrik blok şifrelemesi kullanan ürünler için:

  • Gelişmiş Şifreleme Standardı (AES) önerilir.
  • Şifreleme için kullanılırsa 3DES (Üçlü DES/TDEA) ve RC4 dahil olmak üzere diğer tüm blok şifrelemeleri değiştirilmelidir.

Simetrik blok şifreleme algoritmaları için en az 128 bit anahtar uzunluğu gereklidir, ancak 256 bit anahtarları desteklemenizi öneririz. Yeni kod için önerilen tek blok şifreleme algoritması AES'dir (AES-128, AES-192 ve AES-256' nın tümü kabul edilebilirdir, AES-192'nin bazı işlemcilerde iyileştirme eksikliği olduğuna dikkat edin).

Şifreleme modları

Simetrik algoritmalar, çoğu düz metin ve şifreleme metninin ardışık bloklarındaki şifreleme işlemlerini birbirine bağlayan çeşitli modlarda çalışabilir.

Simetrik blok şifrelemeleri aşağıdaki şifreleme modlarından biriyle kullanılmalıdır:

İzleyenler gibi diğer bazı şifreleme modlarında, bunların yanlış kullanılma olasılığını daha yüksek hale getiren uygulama tuzakları vardır. Özellikle Elektronik Kod Defteri (ECB) çalışma modundan kaçınılmalıdır. CTR gibi "akış şifreleri modlarında" blok şifreleriyle aynı başlatma vektörü (IV) yeniden kullanmak şifrelenmiş verilerin açığa alınmasına neden olabilir. Aşağıdaki modlardan herhangi biri kullanılıyorsa ek güvenlik incelemesi önerilir:

  • Çıkış Geri Bildirimi (OFB)
  • Şifreleme Geri Bildirimi (CFB)
  • Sayaç (CTR)
  • Önceki "önerilen" listede bulunmayan diğer her şey

Başlatma vektörleri (IV)

Tüm simetrik blok şifreleri, başlatma vektöru olarak kriptografik olarak güçlü rastgele bir sayı ile de kullanılmalıdır. Başlatma vektörleri hiçbir zaman sabit veya önlenebilir bir değer olmamalıdır. Kriptografik olarak güçlü rastgele sayılar oluşturma önerileri için bkz. Rastgele Sayı Oluşturucuları.

Başlatma vektörleri, birden çok şifreleme işlemi gerçekleştirilirken hiçbir zaman yeniden kullanılamamalıdır. Yeniden kullanım, özellikle Çıkış Geri Bildirimi (OFB) veya Sayaç (CTR) gibi akış şifreleme modlarını kullanırken şifrelenen veriler hakkındaki bilgileri ortaya çıkarabilir.

AES-GCM & AES-CCM önerileri

AES-GCM (Galois/Sayaç Modu) ve AES-CCM (CBC-MAC ile sayaç) yaygın olarak kimliği doğrulanmış şifreleme modları kullanılır. Gizlilik ve bütünlük korumasını birleştirerek güvenli iletişim için kullanışlı olmalarını sağlar. Ancak, kırılganlıkları nonce yeniden kullanımda yatıyor. Aynı nonce (başlatma vektöru) iki kez kullanıldığında, yıkıcı sonuçlara yol açabilir.

NIST SP 800-38D, Blok Şifreleme Modu İşlemLeri için Öneri: Galois/Sayaç Modu (GCM) ve GMAC'de açıklandığı gibi, çağrı sayısı üst sınırıyla ilgili bölüm 8.3'e özellikle dikkat ederek nonce yönergelerini izlemenizi öneririz.

Şifrelenen her ileti için benzersiz AES-GCM/CCM anahtarları oluşturularak çağrı sayısı üst sınırı etkin bir şekilde 1 olur. Bekleyen verileri şifrelemek için bu yaklaşım önerilir; burada sayaç kullanmak veya belirli bir anahtar için çağrı sayısı üst sınırını izleyebildiğinizden emin olmak pratik olmaz.

Bekleyen verileri şifrelemek için, şifreleme ve MAC için ayrı anahtarlar kullandığınızdan emin olarak, şifreleme ve MAC için ayrı anahtarlar kullandığınızdan emin olmak için, AES-CBC'yi bir ileti kimlik doğrulama koduyla (MAC) alternatif olarak kullanmayı da düşünebilirsiniz.

Bütünlük doğrulaması

Şifrelemenin varsayılan olarak hem gizlilik hem de bütünlük güvencesi sağladığı yaygın bir yanılgıdır. Birçok şifreleme algoritması herhangi bir bütünlük denetimi sağlamaz ve kurcalama saldırılarına karşı savunmasız olabilir. Veri göndermeden önce ve aldıktan sonra verilerin bütünlüğünü sağlamak için ek adımlar atılmalıdır.

AES-GCM gibi ilişkili verilerle (AEAD) kimliği doğrulanmış bir şifreleme algoritması kullanamıyorsanız, bunun bir alternatifi şifreleme ve MAC için ayrı anahtarlar kullandığınızdan emin olmak için Şifrele ve MAC düzeni kullanarak ileti kimlik doğrulama kodu (MAC) ile bütünlüğü doğrulamaktır.

Şifreleme ve MAC için ayrı bir anahtar kullanmak çok önemlidir. İki anahtarı depolamak mümkün değilse, geçerli bir alternatif, biri şifreleme amacıyla ve biri MAC için olmak üzere uygun bir anahtar türetme işlevi (KDF) kullanarak ana anahtardan iki anahtar türetmektir. Daha fazla bilgi için bkz . SP 800-108 Rev. 1, Pseudorandom İşlevlerini Kullanarak Anahtar Türetme Önerisi | CSRC (nist.gov).

Asimetrik algoritmalar, anahtar uzunlukları ve doldurma modları

RSA

  • RSA şifreleme, anahtar değişimi ve imzalar için kullanılabilir.
  • RSA şifrelemesi OAEP veya RSA-PSS doldurma modlarını kullanmalıdır.
  • Mevcut kod yalnızca uyumluluk için PKCS #1 v1.5 doldurma modunu kullanmalıdır.
  • Boş doldurma kullanılması önerilmez.
  • En az 2048 bit anahtar uzunluğu önerilir, ancak 3072 bit anahtar uzunluğunu desteklemenizi öneririz.

ECDSA ve ECDH

  • ECDH tabanlı anahtar değişimi ve ECDSA tabanlı imzalar, NIST onaylı üç eğriden (P-256, P-384 veya P521) birini kullanmalıdır.
  • P-256 desteği en düşük değer olarak kabul edilmelidir, ancak P-384'i desteklemenizi öneririz.

Tamsayı Diffie-Hellman

  • Anahtar uzunluğu >= 2048 bit önerilir0
  • Grup parametreleri iyi bilinen bir adlandırılmış grup olmalıdır (örneğin RFC 7919) veya güvenilir bir taraf tarafından oluşturulmuş ve kullanımdan önce kimliği doğrulanmış olmalıdır.

Anahtar ömrü

  • Tüm anahtarlar için bir cryptoperiod tanımlayın.
    • Örneğin: Veri şifrelemesi için genellikle veri şifreleme anahtarı veya DEK olarak adlandırılan simetrik anahtar, verileri şifrelemek için iki yıla kadar kullanım süresine (kaynak kullanım dönemi olarak da bilinir) sahip olabilir. Üç yıl daha şifre çözme için geçerli bir kullanım süresine sahip olduğunu tanımlayabilirsiniz( alıcı kullanım süresi olarak da bilinir).
  • Sınırlı etkin kullanım ömrü elde etmek için bir mekanizma sağlamalı veya anahtarları değiştirme işleminiz olmalıdır. Etkin ömrü sona erdikten sonra, yeni veri oluşturmak için anahtar kullanılmamalıdır (örneğin, şifreleme veya imzalama için), ancak yine de verileri okumak için (örneğin, şifre çözme veya doğrulama için) kullanılabilir.

Rastgele sayı oluşturucular

Rastgelelik gerektiğinde tüm ürün ve hizmetler kriptografik olarak güvenli rastgele sayı oluşturucular kullanmalıdır.

CNG

  • BCRYPT_USE_SYSTEM_PREFERRED_RNG bayrağıyla BCryptGenRandom kullanın.

Win32/64

  • Eski kod, çekirdek modunda RtlGenRandom kullanabilir.
  • Yeni kod BCryptGenRandom veya CryptGenRandom kullanmalıdır.
  • Rand_s() C işlevi de önerilir (Windows'ta CryptGenRandom'ı çağırır).
  • Rand_s(), Rand() için güvenli ve performanslı bir değiştirmedir.
  • Rand() hiçbir şifreleme uygulaması için kullanılmamalıdır.

.NET

PowerShell

  • Get-SecureRandom (PowerShell) kullanın.

Windows Mağazası uygulamaları

Linux/macOS

  • Cihaz /dev/urandom , sistem çağrıları gibi getrandom(2) rastgele verilerin şifreleme açısından güçlü bir kaynağını sağlar.

Windows platformu tarafından desteklenen şifreleme kitaplıkları

Microsoft, Windows platformunda işletim sisteminde yerleşik olarak bulunan şifreleme API'lerinin kullanılmasını önerir. Diğer platformlarda geliştiriciler, platform dışı şifreleme kitaplıklarını kullanmak üzere değerlendirmeyi tercih edebilir. Genel olarak, platform şifreleme kitaplıkları bir uygulamayla paketlenmek yerine bir işletim sisteminin parçası olarak gönderildiğinden daha sık güncelleştirilir.

Platform ve platform dışı şifreleme ile ilgili tüm kullanım kararları aşağıdaki gereksinimlere göre yönlendirilmelidir:

  • Kitaplık, bilinen güvenlik açıklarından arınan güncel bir destek içi sürüm olmalıdır.
  • En son güvenlik protokolleri, algoritmalar ve anahtar uzunlukları desteklenmelidir.
  • (İsteğe bağlı) Kitaplığın yalnızca geriye dönük uyumluluk için eski güvenlik protokollerini/algoritmalarını destekleyebilecek durumda olması gerekir.

Yerel kod

  • Crypto Primitives: Sürümünüz Windows'daysa mümkünse CNG kullanın.
  • Kod imzası doğrulaması: WinVerifyTrust , Windows platformlarında kod imzalarını doğrulamak için desteklenen API'dir.
  • Sertifika Doğrulama (kod imzalama veya SSL/TLS/DTLS için kısıtlanmış sertifika doğrulamasında kullanılan): CAPI2 API; örneğin, CertGetCertificateChain ve CertVerifyCertificateChainPolicy.

Yönetilen kod (.NET)

Anahtar türetme işlevleri

Anahtar türetmesi, paylaşılan bir gizli diziden veya mevcut bir şifreleme anahtarından şifreleme anahtarı malzemesi türetme işlemidir. Ürünler önerilen anahtar türetme işlevlerini kullanmalıdır. Kullanıcı tarafından seçilen parolalardan anahtar türetme veya kimlik doğrulama sistemindeki depolama için parolaları karmalama, bu kılavuzda ele alınmayan özel bir durumdur; geliştiriciler bir uzmana danışmalıdır.

Aşağıdaki standartlar kullanım için önerilen KDF işlevlerini belirtir:

  • NIST SP 800-108 (Düzeltme 1): Takma Ad İşlevleri Kullanılarak Anahtar Türetme Önerisi. Özellikle, HMAC'nin sahte bir işlev olarak olduğu sayaç modunda KDF
  • NIST SP 800-56A (Düzeltme 3): Ayrık Logaritma Şifrelemesi Kullanan ÇiftEşli Anahtar Oluşturma Düzenleri için Öneri.

Mevcut anahtarlardan anahtar türetmek için algoritmalardan biriyle BCryptKeyDerivation API'sini kullanın:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM
  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Paylaşılan gizli diziden anahtar türetmek için (anahtar sözleşmesinin çıkışı), aşağıdaki algoritmalardan biriyle BCryptDeriveKey API'sini kullanın:

  • BCRYPT_KDF_SP80056A_CONCAT
  • BCRYPT_KDF_HMAC

Sertifika doğrulama

TLS veya DTLS kullanan ürünler, bağlandıkları varlıkların X.509 sertifikalarını tam olarak doğrulamalıdır. Bu işlem, sertifikanın aşağıdaki bölümlerinin doğrulanmasını içerir:

  • Etki alanı adı.
  • Geçerlilik tarihleri (hem başlangıç hem de son kullanma tarihleri).
  • İptal durumu.
  • Kullanım (örneğin, sunucular için "Sunucu Kimlik Doğrulaması", istemciler için "İstemci Kimlik Doğrulaması").
  • Güven zinciri. Sertifikalar, platform tarafından güvenilen veya yönetici tarafından açıkça yapılandırılan bir kök sertifika yetkilisine (CA) zincirlenmelidir.

Bu doğrulama testlerinden herhangi biri başarısız olursa ürün varlıkla bağlantıyı sonlandırmalıdır.

"Otomatik olarak imzalanan" sertifikaları kullanmayın. Otomatik olarak imzalananlar güven, destek iptali veya destek anahtarı yenileme özelliklerini doğal olarak iletmez.

Şifreleme karma işlevleri

Ürünler SHA-2 karma algoritmalar ailesini (SHA-256, SHA-384 ve SHA-512) kullanmalıdır. Güvenlik amacıyla şifreleme karmalarının 128 bitten kısa bir süreye kesilmesine izin verilmez. SHA-256 kullanımı en düşük düzeyde olsa da SHA-384'ün desteklenmesini öneririz.

MAC/HMAC/anahtarlı karma algoritmalar

İleti kimlik doğrulama kodu (MAC), alıcısının gizli anahtar kullanarak hem gönderenin orijinalliğini hem de iletinin bütünlüğünü doğrulamasını sağlayan iletiye eklenmiş bir bilgi parçasıdır.

Karma tabanlı MAC (HMAC) veya blok şifreleme tabanlı MAC kullanımı, temel alınan tüm karma veya simetrik şifreleme algoritmalarının da kullanılması önerilir; şu anda HMAC-SHA2 işlevlerini (HMAC-SHA256, HMAC-SHA384 ve HMAC-SHA512) içerir. HMAC-SHA256 kullanımı en düşük düzeyde olsa da HMAC-SHA384'ü desteklemenizi öneririz.

HMAC'lerin 128 bitten kısa bir süreye kesilmesi önerilmez.

Tasarım ve operasyonel konular

  • Gerektiğinde şifreleme anahtarlarını değiştirmek için bir mekanizma sağlamalısınız. Anahtarlar, etkin yaşamlarının sonuna ulaştıklarında veya şifreleme anahtarı tehlikeye girdikten sonra değiştirilmelidir.
    • Bir sertifikayı her yenilediğinizde, sertifikayı yeni bir anahtarla yenilemeniz gerekir.
  • Verileri korumak için şifreleme algoritmaları kullanan ürünler, gelecekte farklı algoritmalara geçişi desteklemek için bu içerikle birlikte yeterli meta veri içermelidir. Bu meta veriler kullanılan algoritmayı, anahtar boyutlarını ve doldurma modlarını içermelidir.
    • Şifreleme Çevikliği hakkında daha fazla bilgi için Şifreleme Çevikliği makalesine bakın.
  • Ürünler, kullanılabilir olduğunda, imzalama biçimleri de dahil olmak üzere bunları yeniden birleştirmek yerine yerleşik, platform tarafından sağlanan şifreleme protokollerini kullanmalıdır (örneğin, standart ve mevcut bir biçim kullanın).
  • Şifreleme işlemi hatalarını son kullanıcılara bildirmeyin. Bir uzak çağırana hata döndürürken (örneğin, bir istemci-sunucu senaryosunda web istemcisi veya istemci), yalnızca genel bir hata iletisi kullanın.
    • Doğrudan aralık dışı veya geçersiz uzunluk hatalarını raporlama gibi gereksiz bilgiler sağlamaktan kaçının. Yalnızca sunucuda ayrıntılı hataları günlüğe kaydetme ve yalnızca ayrıntılı günlük kaydı etkinse.
  • Aşağıdaki öğeleri içeren tüm tasarımlar için ek güvenlik incelemesi önerilir:
    • Öncelikli olarak güvenliğe odaklanan yeni bir protokol (kimlik doğrulaması veya yetkilendirme protokolü gibi)
    • Şifrelemeyi yeni veya standart olmayan bir şekilde kullanan yeni bir protokol. Dikkat edilmesi gereken örnek noktalar şunlardır:
      • Protokolü uygulayan bir ürün, protokol uygulamasının bir parçası olarak herhangi bir şifreleme API'sini veya yöntemini çağıracak mı?
      • Protokol, kimlik doğrulaması veya yetkilendirme için kullanılan başka bir protokole bağlı mı?
      • Protokol anahtarlar gibi şifreleme öğeleri için depolama biçimlerini tanımlayacak mı?
  • Otomatik olarak imzalanan sertifikalar önerilmez. Ham şifreleme anahtarı kullanımı gibi otomatik olarak imzalanan bir sertifikanın kullanılması, kullanıcılara veya yöneticilere güven kararı vermek için herhangi bir temel sağlamaz.
    • Buna karşılık, güvenilen bir sertifika yetkilisinde köke sahip bir sertifikanın kullanılması, ilişkili özel anahtara güvenmenin temelini netleştirir ve bir güvenlik hatası olduğunda iptal ve güncelleştirmeleri etkinleştirir.