Omfamna kvantklar säkerhet med OpenSSL:s pluggbara PQC för TLS-anslutningar

Snabbt svar: OpenSSLs väg mot kvantklar TLS började med pluggbara post-kvantum-leverantörer i v3.2.0 (november 2023), vilket lät tredjepartsleverantörer som oqs-provider lägga till experimentella PQC-algoritmer utan att modifiera OpenSSL självt. Den övergångsmetoden har sedan dess ersatts: OpenSSL 3.5, släppt som en LTS-version den 8 april 2025, levererar inbyggt stöd för ML-KEM, ML-DSA och SLH-DSA, och standardinställningen för TLS 1.3-nyckelutbyte är hybridgruppen X25519MLKEM768. Den rekommenderade åtgärden är att uppgradera direkt till OpenSSL 3.5 LTS snarare än att bygga vidare på den äldre pluggbara-provider-metoden, eftersom inbyggt stöd tar bort det extra beroendet och fortsätter att stödjas till och med april 2030.

Key Takeaways

• OpenSSL v3.2.0 (november 2023) introducerade pluggbara PQC-leverantörer, vilket låter tredjepartsbibliotek som oqs-provider lägga till post-kvantumalgoritmer experimentellt.
• OpenSSL 3.5, en LTS-utgåva från den 8 april 2025, ersatte den övergångsmetoden med inbyggt stöd för ML-KEM (FIPS 203), ML-DSA (FIPS 204) och SLH-DSA (FIPS 205) inbyggt direkt i standardleverantören.
• OpenSSL 3.5:s standardlista över TLS 1.3-stödda grupper föredrar nu hybrid PQC-nyckelutbyte, med X25519MLKEM768 och X25519 som standardnyckeldelningar.
• ML-KEM kräver TLS 1.3 och kan inte användas med TLS 1.2 eller tidigare; SLH-DSA-signaturer är stora (8 till 50 KB), så ML-DSA föredras generellt för certifikat där storleken har betydelse.
• OpenSSL 3.5 LTS stöds fram till den 8 april 2030, vilket täcker den period då de flesta globala PQC-migreringsfristerna träder i kraft.

Utgångspunkten för den pluggbara leverantören

Under senare år har kvantberäkningar framstått som ett mycket transformerande område. Kvantdatorer eller maskiner använder kvantmekaniska processer för att lösa problem främst relaterade till matematiska beräkningar som är svåra för konventionella datorer. Postkvantkryptografi (PQC) syftar till att skapa kryptografiska mekanismer som ger säkerhet för både kvant- och konventionella datorer och följer befintliga kommunikationsprotokoll och nätverk. OpenSSL är en viktig aktör inom området säkra kommunikationstekniker. I sin v3.2.0-release (november 2023) introducerade OpenSSL stöd för pluggbara postkvantkryptografiska (PQC) signaturalgoritmer och nyckelupprättandemekanismer.

Pluggbara signaturalgoritmer

Den mest intressanta funktionen med den utgåvan var att integrera pluggbara signaturalgoritmer. Detta gjorde det möjligt för tredjepartsleverantörer, såsom Open Quantum Safe-projektets oqs-provider, att integrera post-kvantumkryptografiska tekniker utan att modifiera OpenSSLs kärnkodbas. Detta förbättrade också OpenSSLs anpassningsförmåga, vilket gjorde det möjligt för användare att välja PQC- scheman som anpassades till deras specifika säkerhetsbehov vid en tidpunkt då NIST ännu inte hade slutfört sina standarder. Dilithium (senare standardiserat som ML-DSA) var en av de mest anmärkningsvärda kandidaterna som testades på detta sätt, en robust och säker signaturalgoritm utformad för att motstå kvantenheters beräkningskraft.

Mekanismer för etablering av inkopplingsbara nyckelringar

Vid sidan av pluggbara signaturer stödde OpenSSLs leverantörsarkitektur även pluggbara nyckelupprättandemekanismer (KEM), vilket introducerade algoritmer som Kyber (senare standardiserat som ML-KEM) till TLS- ekosystemet via tredjepartsleverantörer. Denna kombination positionerade OpenSSL som ett anpassningsbart, kvantklart TLS-bibliotek före formell standardisering, vilket lät användare experimentera med kandidat- PQC- algoritmer för signaturgenerering och nyckelupprättande under TLS-handskakningen.

OpenSSL 3.5 LTS: Inbyggt PQC-stöd anländer

Metoden med pluggbar leverantör har alltid varit en brygga, inte en destination. NIST slutförde ML-KEM (FIPS 203), ML-DSA (FIPS 204) och SLH-DSA (FIPS 205) den 13 augusti 2024, och OpenSSL införde alla tre i sin standardleverantör med lanseringen av OpenSSL 3.5.0 den 8 april 2025. Till skillnad från den tidigare pluggbara metoden levereras detta stöd direkt, utan krav på extern leverantör eller patch.

OpenSSL 3.5 är också en långsiktig stabil (LTS) version, som stöds med uppdateringar i fem år fram till den 8 april 2030, ett fönster som täcker de flesta av de globala PQC-migreringsdeadlines som organisationer nu planerar mot. Versionen ändrade även OpenSSLs standard TLS-beteende: listan över standardgrupper som stöds inkluderar och föredrar nu hybrid PQC-nyckelutbyte, med X25519MLKEM768 och X25519 som standardnyckeldelningar. Det innebär att organisationer som kör OpenSSL 3.5 med standardinställningar redan förhandlar om hybrid post-quantum-nyckelutbyte för TLS 1.3-anslutningar utan ytterligare konfiguration.

Några praktiska begränsningar följer av själva algoritmerna. ML-KEM kräver TLS 1.3 och kan inte förhandlas över TLS 1.2 eller tidigare. SLH-DSA-signaturer varierar från 8 till 50 KB beroende på parameteruppsättningen, betydligt större än ML-DSA-signaturer, så ML-DSA är den mer praktiska standarden för TLS-certifikat där handskakningsstorleken spelar roll. SLH-DSA är fortfarande värdefull där dess mer konservativa, hashbaserade säkerhetsantaganden är värda storleksavvägningen.

Kvantförberedd flexibilitet

Mellan de pluggbara providers som introducerades i v3.2.0 och det inbyggda standardstödet i 3.5 har OpenSSLs TLS-bibliotek byggt in verklig flexibilitet i övergången. Organisationer som experimenterade tidigt med oqs-provider har nu en direkt uppgraderingsväg till standardiserade, inbyggda algoritmer, och organisationer som börjar om från början kan anta OpenSSL 3.5 LTS direkt. Denna flexibilitet håller OpenSSL steget före det föränderliga cybersäkerhetslandskapet och håller kommunikationskanalerna uppdaterade med slutgiltiga NIST-standarder snarare än utkast till kandidater.

Implementeringsöverväganden

Organisationer som använder postkvantkryptografiska algoritmer för specifika användningsfall måste noggrant överväga implementeringsstrategier. OpenSSL 3.5:s inbyggda stöd förenklar detta avsevärt jämfört med den tidigare pluggable-provider-metoden, eftersom algoritmerna redan är validerade och inkluderade i varje standardversion, men korrekt testning och validering är fortfarande avgörande. Detta inkluderar att jämföra den verkliga kostnaden för större PQC-nycklar och signaturer på din specifika infrastruktur, verifiera interoperabilitet med klienter och servrar som ännu inte har uppgraderats, och bekräfta om din distribution behöver FIPS-validerade versioner, eftersom PQC-stöd i FIPS-leverantören följer standardleverantören.

Slutsats

I takt med att cybersäkerhetslandskapet fortsätter att utvecklas står vi, Encryption Consulting, som en betrodd partner som är experter på att vägleda organisationer att integrera dessa senaste säkerhetsåtgärder sömlöst.

Genom att samarbeta med oss ​​får organisationer en strategisk allierad i kampen mot framväxande cyberhot. Vårt team är förberett att få tillgång till, planera och genomföra integrationen av inbyggd postkvantkryptografi med OpenSSL-biblioteket. Vi säkerställer att organisationer navigerar framgångsrikt för att säkra kommunikationen med förstärkta kryptografiska funktioner.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan OpenSSLs pluggbara PQC-leverantörer och OpenSSL 3.5s inbyggda stöd?

Pluggbara leverantörer, introducerade i v3.2.0, låter tredjepartsbibliotek som oqs-provider lägga till experimentella post-kvantumalgoritmer utan att modifiera OpenSSLs kärnkod. OpenSSL 3.5 byggde ML-KEM, ML-DSA och SLH-DSA direkt i OpenSSLs standardleverantör, så ingen extern leverantör behövs och algoritmerna är de NIST-slutgiltiga standarderna snarare än förstandardiserade kandidater.

När släpptes OpenSSL 3.5, och hur länge stöds det?

OpenSSL 3.5.0 släpptes den 8 april 2025 som en långsiktig stabil (LTS) version. Den får säkerhetsuppdateringar i fem år, fram till den 8 april 2030.

Vilket är standardnyckelutbytet för TLS 1.3 i OpenSSL 3.5?

OpenSSL 3.5 har som standard inställt sin lista över stödda grupper på att föredra hybrid post-quantum-nyckelutbyte, och erbjuder X25519MLKEM768 och X25519 som standardnyckeldelningar. Organisationer som kör standardkonfigurationer förhandlar redan om hybrid PQC-nyckelutbyte för TLS 1.3 utan extra konfiguration.

Kan ML-KEM användas med TLS 1.2?

Nej. ML-KEM kräver TLS 1.3 och kan inte förhandlas över TLS 1.2 eller tidigare protokollversioner.

Ska jag använda ML-DSA eller SLH-DSA för certifikat?

ML-DSA är den mer praktiska standardinställningen för de flesta certifikat, eftersom SLH-DSA-signaturer varierar från 8 till 50 KB beroende på parameteruppsättningen, betydligt större än ML-DSA. SLH-DSA är värd storleksavvägningen där dess mer konservativa, hashbaserade säkerhetsantaganden är viktigare än handskakningseffektivitet.

Om jag redan har distribuerat den pluggbara metoden oqs-provider, behöver jag migrera?

Ja, så småningom. Metoden med pluggbar leverantör byggdes kring kandidatalgoritmer som var förstandardiserade. Genom att migrera till OpenSSL 3.5:s inbyggda stöd får du NIST-slutgiltiga versioner av dessa algoritmer utan externa beroenden, och du slipper underhållsbördan av att spåra ett separat leverantörsprojekt.