Använd endast godkända symmetriska block chiffer och nyckellängder
Rubrik
Information
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Produkter får endast använda de symmetriska blockchiffreringar och associerade nyckellängder som uttryckligen har godkänts av Kryptorådgivaren i din organisation. Godkända symmetriska algoritmer på Microsoft innehåller följande block chiffer:
För den nya koden är AES-128, AES-192 och AES-256 godtagbara
För bakåtkompatibilitet med befintlig kod är 3DES med tre nycklar acceptabelt
För produkter som använder symmetriska block chiffer:
Advanced Encryption Standard (AES) krävs för ny kod
Trenycklars trippel datakrypteringsstandard (3DES) är tillåten i befintlig kod för bakåtkompatibilitet
Alla andra block chiffer, inklusive RC2, DES, 2 Key 3DES, DESX och Skipjack, kan endast användas för dekryptering av gamla data och måste ersättas om de används för kryptering
För symmetriska blockkrypteringsalgoritmer krävs en minsta nyckellängd på 128 bitar. Den enda blockkrypteringsalgoritm som rekommenderas för ny kod är AES (AES-128, AES-192 och AES-256 är alla acceptabla)
3DES med tre nycklar är för närvarande acceptabelt om det redan används i befintlig kod. övergången till AES rekommenderas. DES, DESX, RC2 och Skipjack anses inte längre vara säkra. Dessa algoritmer kan endast användas för att dekryptera befintliga data för bakåtkompatibilitet, och data bör krypteras igen med hjälp av ett rekommenderat block chiffer
Observera att alla symmetriska block chiffer måste användas med ett godkänt chifferläge, vilket kräver användning av en lämplig initieringsvektor (IV). En lämplig IV, är vanligtvis ett slumpmässigt tal och aldrig ett konstant värde
Användning av äldre eller på annat sätt ej godkända kryptoalgoritmer och mindre nyckellängder för att läsa befintliga data (i stället för att skriva nya data) kan tillåtas efter organisationens granskning av kryptografinämnden. Du måste dock ansöka om ett undantag mot det här kravet. I företagsdistributioner bör produkter dessutom överväga varningsadministratörer när svag kryptografi används för att läsa data. Sådana varningar bör vara förklarande och handlingsbara. I vissa fall kan det vara lämpligt att ha grupprincip styra användningen av svag kryptografi
Tillåtna .NET-algoritmer för agilitet för hanterad kryptografi (i prioritetsordning)
AesCng (FIPS-kompatibel)
AuthenticatedAesCng (FIPS-kompatibel)
AESCryptoServiceProvider (FIPS-kompatibel)
AESManaged (icke-FIPS-kompatibel)
Observera att ingen av dessa algoritmer kan anges via SymmetricAlgorithm.Create metoderna eller CryptoConfig.CreateFromName utan att göra ändringar i machine.config-filen. Observera också att AES i versioner av .NET före .NET 3.5 heter RijndaelManagedoch AesCngAuthenticatedAesCng är >tillgängliga via CodePlex och kräver CNG i det underliggande operativsystemet
Använda godkända block chifferlägen och initieringsvektorer för symmetriska chiffer
Rubrik
Information
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Alla symmetriska blockchiffreringar måste användas med ett godkänt symmetriskt chifferläge. De enda godkända lägena är CBC och CTS. I synnerhet bör den elektroniska kodbokens funktionssätt (ECB) undvikas. användning av ECB kräver organisationens granskning av kryptografinämnden. All användning av OFB, CFB, CTR, CCM och GCM eller något annat krypteringsläge måste granskas av organisationens kryptografikort. Återanvändning av samma initieringsvektor (IV) med block chiffer i "strömmande chifferlägen", till exempel CTR, kan orsaka att krypterade data avslöjas. Alla symmetriska block chiffer måste också användas med en lämplig initieringsvektor (IV). En lämplig IV är ett kryptografiskt starkt, slumpmässigt tal och aldrig ett konstant värde.
Använda godkända asymmetriska algoritmer, nyckellängder och utfyllnad
Rubrik
Information
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Användningen av förbjudna kryptografiska algoritmer medför betydande risker för produktsäkerheten och måste undvikas. Produkter får endast använda de kryptografiska algoritmer och tillhörande nyckellängder och utfyllnad som uttryckligen har godkänts av organisationens kryptografikort.
RSA – kan användas för kryptering, nyckelutbyte och signatur. RSA-kryptering får endast använda utfyllnadslägena OAEP eller RSA-KEM. Befintlig kod kan endast använda PKCS #1 v1.5-utfyllnadsläge för kompatibilitet. Användning av null-utfyllnad är uttryckligen förbjuden. Nycklar >= 2 048 bitar krävs för ny kod. Befintlig kod kan endast ha stöd för nycklar < 2048 bitar för bakåtkompatibilitet efter en granskning av organisationens kryptokort. Nycklar < 1024 bitar får endast användas för dekryptering/verifiering av gamla data och måste ersättas om de används för krypterings- eller signeringsåtgärder
ECDSA – kan endast användas för signatur. ECDSA med >=256-bitarsnycklar krävs för ny kod. ECDSA-baserade signaturer måste använda en av de tre NIST-godkända kurvorna (P-256, P-384 eller P521). Kurvor som har analyserats noggrant kan endast användas efter en granskning med organisationens crypto board.
ECDH- kan endast användas för nyckelutbyte. ECDH med >=256-bitarsnycklar krävs för ny kod. ECDH-baserat nyckelutbyte måste använda en av de tre NIST-godkända kurvorna (P-256, P-384 eller P521). Kurvor som har analyserats noggrant kan endast användas efter en granskning med organisationens crypto board.
DSA – kan vara acceptabelt efter granskning och godkännande från organisationens crypto board. Kontakta din säkerhetsrådgivare för att schemalägga organisationens crypto board-granskning. Om din användning av DSA godkänns måste du förbjuda användning av nycklar som är mindre än 2 048 bitar långa. CNG stöder 2048-bitars och större nyckellängder från och med Windows 8.
Diffie-Hellman– kan endast användas för hantering av sessionsnycklar. Nyckellängd >= 2 048 bitar krävs för ny kod. Befintlig kod kan endast ha stöd för nyckellängder < 2048 bitar för bakåtkompatibilitet efter en granskning av organisationens kryptostyrelse. Nycklar < 1024 bitar kanske inte används.
Använda godkända slumptalsgeneratorer
Rubrik
Information
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Produkter måste använda godkända slumptalsgeneratorer. Pseudorandomfunktioner som C-körningsfunktionen rand, .NET Framework-klassen System.Random eller systemfunktioner som GetTickCount måste därför aldrig användas i sådan kod. Det är förbjudet att använda slumptalsgeneratorn med dubbla elliptiska kurvor (DUAL_EC_DRBG)
CNG- BCryptGenRandom(användning av flaggan BCRYPT_USE_SYSTEM_PREFERRED_RNG rekommenderas om inte anroparen kan köras på en IRQL som är större än 0 [det vill sig PASSIVE_LEVEL])
CAPI- cryptGenRandom
Win32/64- RtlGenRandom (nya implementeringar bör använda BCryptGenRandom eller CryptGenRandom) * rand_s * SystemPrng (för kernelläge)
. NET – RNGCryptoServiceProvider eller RNGCng
Windows Store-appar – Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom eller . GenerateRandomNumber
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
Apple OS X (<10.7)- Använd /dev/random för att hämta slumpmässiga tal
Java (inklusive Google Android Java-kod)- java.security.SecureRandom-klass. Observera att för Android 4.3 (Jelly Bean) måste utvecklare följa den rekommenderade Android-lösningen och uppdatera sina program för att uttryckligen initiera PRNG med entropin från /dev/urandom eller /dev/random
Använd inte symmetriska ström chiffer
Rubrik
Information
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Symmetriska ström chiffer, till exempel RC4, får inte användas. I stället för symmetriska ström chiffer bör produkter använda ett block chiffer, särskilt AES med en nyckellängd på minst 128 bitar.
Använda godkända MAC/HMAC/nyckelade hashalgoritmer
Rubrik
Information
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Produkter får endast använda godkända autentiseringskoder för meddelanden (MAC) eller hashbaserade algoritmer för meddelandeautentisering (HMAC).
En kod för meddelandeautentisering (MAC) är en information som är kopplad till ett meddelande som gör att mottagaren kan verifiera både avsändarens äkthet och meddelandets integritet med hjälp av en hemlig nyckel. Användning av antingen en hashbaserad MAC (HMAC) eller blockkrypteringsbaserad MAC är tillåten så länge alla underliggande hash- eller symmetriska krypteringsalgoritmer också är godkända för användning. för närvarande omfattar detta funktionerna HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 och HMAC-SHA512) och CMAC/OMAC1 och OMAC2 block chifferbaserade MACs (dessa baseras på AES).
Användning av HMAC-SHA1 kan vara tillåtet för plattformskompatibilitet, men du måste lämna in ett undantag från den här proceduren och genomgå organisationens kryptogranskning. Trunkering av HMACs till mindre än 128 bitar tillåts inte. Användning av kundmetoder för att hasha en nyckel och data godkänns inte och måste genomgå organisationens crypto board-granskning innan den används.
Använd endast godkända kryptografiska hashfunktioner
Rubrik
Information
Komponent
Webbprogram
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Produkter måste använda SHA-2-serien med hashalgoritmer (SHA256, SHA384 och SHA512). Om en kortare hash behövs, till exempel en 128-bitars utdatalängd för att passa en datastruktur som utformats med den kortare MD5-hashen i åtanke, kan produktteam trunkera en av SHA2-hashvärdena (vanligtvis SHA256). Observera att SHA384 är en trunkerad version av SHA512. Trunkering av kryptografiska hashvärden i säkerhetssyfte till mindre än 128 bitar tillåts inte. Ny kod får inte använda MD2-, MD4-, MD5-, SHA-0-, SHA-1- eller RIPEMD-hashalgoritmerna. Hash-kollisioner är beräkningsmässigt genomförbara för dessa algoritmer, vilket effektivt bryter dem.
Tillåtna .NET-hashalgoritmer för hanterad kryptoflexiitet (i prioritetsordning):
SHA512Cng (FIPS-kompatibel)
SHA384Cng (FIPS-kompatibel)
SHA256Cng (FIPS-kompatibel)
SHA512Managed (icke-FIPS-kompatibel) (använd SHA512 som algoritmnamn i anrop till HashAlgorithm.Create eller CryptoConfig.CreateFromName)
SHA384Managed (icke-FIPS-kompatibel) (använd SHA384 som algoritmnamn i anrop till HashAlgorithm.Create eller CryptoConfig.CreateFromName)
SHA256Managed (icke-FIPS-kompatibel) (använd SHA256 som algoritmnamn i anrop till HashAlgorithm.Create eller CryptoConfig.CreateFromName)
SHA512CryptoServiceProvider (FIPS-kompatibel)
SHA256CryptoServiceProvider (FIPS-kompatibel)
SHA384CryptoServiceProvider (FIPS-kompatibel)
Använda starka krypteringsalgoritmer för att kryptera data i databasen
Krypteringsalgoritmer definierar datatransformeringar som inte enkelt kan ångras av obehöriga användare. SQL Server låter administratörer och utvecklare välja bland flera algoritmer, inklusive DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bitars RC4, DESX, 128-bitars AES, 192-bitars AES och 256-bitars AES
Källan till ett paket är den person eller organisation som skapade paketet. Det kan vara riskabelt att köra ett paket från en okänd eller obetrodd källa. För att förhindra obehörig manipulering av SSIS-paket bör digitala signaturer användas. För att säkerställa paketens konfidentialitet under lagring/överföring måste SSIS-paket också krypteras
Lägga till digital signatur i viktiga databassäkringar
I de fall där integriteten för en kritisk databas som kan skyddas måste verifieras bör digitala signaturer användas. Databassäkringsbara objekt som en lagrad procedur, funktion, sammansättning eller utlösare kan signeras digitalt. Nedan visas ett exempel på när detta kan vara användbart: Låt oss säga att en ISV (oberoende programvaruleverantör) har gett stöd till en programvara som levereras till en av deras kunder. Innan du ger support vill ISV se till att en databas som kan säkras i programvaran inte manipulerades av misstag eller av ett skadligt försök. Om den säkra filen är digitalt signerad kan ISV:en verifiera den digitala signaturen och verifiera dess integritet.
Använda SQL Server EKM för att skydda krypteringsnycklar
SQL Server Extensible Key Management gör det möjligt att lagra krypteringsnycklarna som skyddar databasfilerna på en extern enhet, till exempel smartkort, USB-enhet eller EKM/HSM-modul. Detta möjliggör även dataskydd från databasadministratörer (förutom medlemmar i sysadmin-gruppen). Data kan krypteras med hjälp av krypteringsnycklar som endast databasanvändaren har åtkomst till i den externa EKM/HSM-modulen.
Använd AlwaysEncrypted-funktionen om krypteringsnycklar inte ska visas för databasmotorn
Always Encrypted är en funktion som är utformad för att skydda känsliga data, till exempel kreditkortsnummer eller nationella/regionala ID-nummer (t.ex. socialförsäkringsnummer i USA), som lagras i Azure SQL Database eller SQL Server databaser. Always Encrypted tillåter att klienter krypterar känsliga data i klientprogram och aldrig avslöjar krypteringsnycklarna för databasmotorn (SQL Database eller SQL Server). Därför ger Always Encrypted en separation mellan dem som äger data (och kan visa dem) och de som hanterar data (men som inte bör ha någon åtkomst)
Lagra kryptografiska nycklar på ett säkert sätt på IoT-enheten
Rubrik
Information
Komponent
IoT-enhet
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Enhetsoperativsystem – Windows IoT Core, Enhetsanslutning – SDK:er för Azure IoT-enheter
Symmetriska eller privata certifikatnycklar på ett säkert sätt i ett maskinvaruskyddat lagringsutrymme som TPM eller smartkortschips. Windows 10 IoT Core stöder användaren av en TPM och det finns flera kompatibla TPM:er som kan användas: Diskret TPM (dTPM). Vi rekommenderar att du använder en inbyggd programvara eller diskret TPM. En TPM för programvara bör endast användas i utvecklings- och testningssyfte. När en TPM är tillgänglig och nycklarna har etablerats i den ska koden som genererar token skrivas utan hårdkodning av känslig information i den.
Exempel
TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM
string hubUri = myDevice.GetHostName();
string deviceId = myDevice.GetDeviceId();
string sasToken = myDevice.GetSASToken();
var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);
Som du ser finns inte enhetens primärnyckel i koden. I stället lagras den i TPM på plats 0. TPM-enheten genererar en kortlivad SAS-token som sedan används för att ansluta till IoT Hub.
Generera en slumpmässig symmetrisk nyckel med tillräcklig längd för autentisering för att IoT Hub
Rubrik
Information
Komponent
IoT Cloud Gateway
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Gatewayval – Azure IoT Hub
Referenser
Ej tillämpligt
Steg
IoT Hub innehåller ett enhetsidentitetsregister och genererar automatiskt en slumpmässig symmetrisk nyckel när du etablerar en enhet. Vi rekommenderar att du använder den här funktionen i Azure IoT Hub Identity Registry för att generera nyckeln som används för autentisering. IoT Hub gör det också möjligt att ange en nyckel när enheten skapas. Om en nyckel genereras utanför IoT Hub under enhetsetablering rekommenderar vi att du skapar en slumpmässig symmetrisk nyckel eller minst 256 bitar.
Se till att det finns en princip för enhetshantering som kräver en PIN-kod för användning och tillåter fjärrrensning
Rubrik
Information
Komponent
Dynamics CRM Mobile Client
SDL-fas
Distribution
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Se till att det finns en princip för enhetshantering som kräver en PIN-kod för användning och tillåter fjärrrensning
Se till att det finns en princip för enhetshantering som kräver pin-kod/lösenord/automatiskt lås och krypterar alla data (t.ex. BitLocker)
Rubrik
Information
Komponent
Dynamics CRM Outlook-klient
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Se till att det finns en princip för enhetshantering som kräver pin-kod/lösenord/automatiskt lås och krypterar alla data (t.ex. BitLocker)
Se till att signeringsnycklarna överförs när du använder Identity Server
Se till att signeringsnycklarna överförs när du använder Identity Server. Länken i referensavsnittet förklarar hur detta bör planeras utan att orsaka avbrott för program som förlitar sig på identitetsservern.
Se till att kryptografiskt starkt klient-ID, klienthemlighet används i Identity Server
Rubrik
Information
Komponent
Identitetsserver
SDL-fas
Skapa
Tillämpliga tekniker
Allmänna
Attribut
Ej tillämpligt
Referenser
Ej tillämpligt
Steg
Se till att kryptografiskt starkt klient-ID, klienthemlighet används i Identity Server. Följande riktlinjer bör användas när du genererar ett klient-ID och en hemlighet:
Generera ett slumpmässigt GUID som klient-ID
Generera en kryptografiskt slumpmässig 256-bitarsnyckel som hemlighet