Förstå elliptisk kurvkryptografi (ECC)

Elliptisk kurvkryptografi (ECC) är en form av kryptografi med publika nyckelr baserad på den algebraiska strukturen hos elliptiska kurvor över ändliga fält. Den uppnår samma säkerhetsmål som RSA , inklusive nyckelutbyte, digitala signaturer och autentisering, med betydligt mindre nyckelstorlekar, snabbare operationer och lägre resursförbrukning. En 256-bitars ECC-nyckel ger ungefär samma säkerhet som en 3072-bitars RSA-nyckel. Rekommenderad åtgärd: använd ECDSA P-256 eller Ed25519 för nya digitala signaturer och TLS-certifikat, ECDHE för nyckelutbyte i TLS 1.3, och börja planera migrering till post-kvantum-ersättningar (ML-KEM, ML-DSA) för långlivad infrastruktur där tidslinjen för utfasning 2030 gäller.

Snabbt svar: Vad är ECC och när ska du använda det?

ECC är den föredragna asymmetriska kryptografiska algoritmen för de flesta nya implementeringar: TLS-certifikat, kodsignering, SSH-nycklar och mobil/IoT-autentisering. Dess säkerhet bygger på Elliptic Curve Discrete Logarithm Problem (ECDLP), som inte har någon känd subexponentiell lösning på en väl vald kurva. Fördel med nyckelstorlek: ECDSA P-256 ger 128-bitars säkerhet med en 32-byte-nyckel; RSA behöver en 3072-bitars (384-byte) nyckel för motsvarande säkerhet. Använd ECC för nya certifikat, SSH-nycklar och kodsignering. Använd RSA endast där ECC inte stöds av äldre system. Obs: ECC är inte kvantsäker; Shors algoritm bryter mot ECDLP. Planera migrering till NIST-standardiserade postkvantalgoritmer för infrastruktur med fleråriga nyckellivstider.

Vad är elliptisk kurvkryptografi (ECC)?

ECC är en typ av kryptografi med publik nyckel där man har två matematiskt relaterade nycklar: en som man delar offentligt (den publika nyckeln) och en som man håller hemlig (den privata nyckeln). Det som gör ECC unikt är dess användning av elliptiska kurvor: matematiska strukturer definierade över ändliga fält av en ekvation av formen y² = x³ + ax + b . Matematiker studerade dessa kurvor i århundraden, men 1985 upptäckte Neal Koblitz och Victor S. Miller oberoende av varandra deras tillämpning inom kryptografi, vilket möjliggjorde stark säkerhet med mycket mindre nycklar än tidigare metoder som RSA.

Säkerheten för ECC vilar på det elliptiska kurvans diskreta logaritmproblem (ECDLP) : givet en baspunkt G på kurvan och en resulterande punkt P beräknad som P = kG (genom skalär multiplikation, som upprepade gånger adderar G till sig själv k gånger enligt kurvans regler), är det beräkningsmässigt ogenomförbart att hitta k givet endast G och P. Det finns ingen känd algoritm som löser ECDLP betydligt snabbare än råstyrka på en väl vald kurva, vilket är anledningen till att små ECC-nycklar ger stark säkerhet.

Hur ECDH-nyckelutbyte fungerar

ECDH (Elliptic Curve Diffie-Hellman) är nyckelutbytesprotokollet som är byggt på ECC. Det tillåter två parter att upprätta en delad hemlighet över en osäker kanal utan att själva hemligheten överförs. Så här fungerar det med Alice och Bob som exempel:

Alice och Bob kommer öppet överens om en specifik elliptisk kurva och en startbaspunkt G på den kurvan. Alice väljer ett hemligt tal a (hennes privata nyckel) och beräknar sin publika nyckel A = aG (skalär multiplikation av G med a). Bob väljer ett hemligt tal b (sin privata nyckel) och beräknar sin publika nyckel B = bG. Båda utbyter sina publika nycklar A och B öppet.

Alice beräknar den delade hemligheten: aB = a(bG) = abG. Bob beräknar samma delade hemlighet: bA = b(aG) = abG. Båda anländer till samma punkt abG på kurvan, vilket blir den delade hemligheten. En tjuvlyssnare som observerar G, A och B kan inte beräkna den delade hemligheten abG utan att lösa ECDLP, det vill säga att hitta antingen a från G och A, eller b från G och B, vilket är beräkningsmässigt ogenomförbart.

I praktiken genererar ECDHE (Ephemeral ECDH) ett nytt nyckelpar för varje session, och de efemära privata nycklarna tas bort efteråt. Detta ger framåtriktad sekretess : att kompromettera långsiktiga nycklar senare kan inte dekryptera tidigare sessioner eftersom de efemära sessionsnycklarna är borta. TLS 1.3 kräver ECDHE för alla nyckelutbyten, vilket gör framåtriktad sekretess obligatorisk. Se vår guide om TLS 1.2 och TLS 1.3 för hur detta tillämpas i praktiken.

ECC kontra RSA

RSA och ECC uppnår båda målen med kryptografi med publika nyckeln men genom olika matematiska grunder. RSA bygger på svårigheten att faktorisera stora heltal medan ECC bygger på ECDLP. De praktiska skillnaderna är betydande:

Leverans	RSA	ECC
Säkerhet baserad på	Heltalsfaktorisering	Elliptisk kurva diskret logaritmproblem (ECDLP)
Nyckelstorlek för 128-bitars säkerhet	3072 bitar	256 bitar (ECDSA P-256)
Nyckelstorlek för 192-bitars säkerhet	7680 bitar	384 bitar (ECDSA P-384)
Signeringsprestanda	Långsam (stor modulär exponentiering)	Snabb
Verifieringsprestanda	Snabb	Snabb
Påverkan på certifikatstorlek	Stor (RSA-3072-certifikat ~384 byte för offentlig nyckel)	Liten (ECDSA P-256-certifikat ~32 byte för offentlig nyckel)
Bäst lämpad för	Äldre system som kräver RSA-kompatibilitet	Nya implementeringar: TLS, SSH, kodsignering, IoT, mobil
Kvantsäkerhet	Inte kvantsäker (Shors algoritm bryter RSA)	Inte kvantsäker (Shors algoritm bryter mot ECDLP)

Jämförelse av säkerhetsstyrkor mellan algoritmfamiljer

NIST SP 800-57 Del 1 Rev. 5 definierar likvärdiga säkerhetsnivåer för symmetriska, ECC- och RSA-algoritmer. Detta gör det möjligt för säkerhetsarkitekter att välja algoritmer som ger likvärdigt skydd utan att överskrida beräkningskostnaderna:

Säkerhetsstyrka (bitar)	Symmetrisk nyckelstorlek	ECC-nyckelstorlek	RSA-nyckelstorlek
128	AES-128	256-283 bitar (P-256)	3072 bitar
192	AES-192	384-511 bitar (P-384)	7680 bitar
256	AES-256	512+ bitar (P-521)	15360 bitar

ECC uppnår samma säkerhet som RSA med dramatiskt mindre nycklar. För det vanligaste distributionsmålet för 128-bitars säkerhet: ECDSA P-256 (32-byte offentlig nyckel) jämfört med RSA-3072 (384-byte offentlig nyckel). Denna storleksskillnad spelar en betydande roll för TLS-certifikatstorlek, DNSSEC-svarsstorlek och resursbegränsade enheter. ECC:s fördel är mest uttalad i miljöer där bandbredd, lagring eller beräkningsförmåga är begränsad: mobila applikationer, IoT-enheter , smartkort och inbyggda system.

ECC-algoritm och vägledning för kurvval

Användningsfall	Rekommenderad ECC-algoritm/kurva	Varför	Undvik
TLS-certifikat (nya distributioner)	ECDSA P-256	128-bitars säkerhet; brett stöd; mindre certifikat minskar TLS-handskakningsstorleken; NIST SP 800-52 Rev. 2 rekommenderas	RSA-2048 (föreslagen utfasad efter 2030 enligt NIST IR 8547)
TLS-nyckelutbyte (sessionsnycklar)	ECDHE X25519 eller P-256	Tillfälligt nyckelutbyte ger framåtriktad sekretess; TLS 1.3 kräver ECDHE för alla anslutningar	RSA-nyckelutbyte (ingen framåtriktad sekretess; borttaget från TLS 1.3)
SSH-nycklar	Ed25519	Edwards-kurva DSA; 128-bitars säkerhet; 32-byte publik nyckel; snabb; motståndskraftig mot tidsrelaterade sidokanalattacker; stöds av OpenSSH 6.5+	DSA (föråldrad); RSA-1024 (osäker); ECDSA P-256 (acceptabelt alternativ om Ed25519 inte är tillgänglig)
Kodsignering	ECDSA P-256 eller P-384	Mindre signaturer än RSA med motsvarande säkerhet; snabbare signering; viktigt för signeringspipelines med hög genomströmning	RSA-1024 (osäker); SHA-1 som hash (trasig)
DNSSEC-zonsignering	ECDSA P-256	Mindre signaturer passar DNS UDP-svar lättare; minskad zonstorlek	RSA-1024 (osäker); RSA-2048 (betydligt större signaturer)
Mobil- och IoT-autentisering	ECDSA P-256 eller Ed25519	Lägre beräknings-, ström- och bandbreddskrav jämfört med RSA med motsvarande säkerhet	RSA-3072+ (högre beräkningskostnader på begränsad hårdvara)
Postkvantmigrering (nyckelutbyte)	ML-KEM (FIPS 203)	NIST-standardiserad PQC-ersättning för ECDH; resistent mot Shors algoritm	ECDH ensamt för ny långlivad infrastruktur

För- och nackdelar med ECC

Fördelar med ECC

• Mindre nyckelstorlek vid motsvarande säkerhet: ECC uppnår 128-bitars säkerhet med en 256-bitars nyckel jämfört med 3072 bitar för RSA. Mindre nycklar minskar lagringskrav, bandbredd för certifikatöverföring och beräkningstid.
• Stark matematisk grund: Ingen känd subexponentiell attack existerar mot ECDLP på väl valda kurvor. Detta ger robust säkerhet utan att förlita sig på algoritmobskyrhet.
• Vidarebefordran av sekretess via ECDHE: ECDHE möjliggör kortlivat nyckelutbyte och tillhandahåller framåtriktad sekretess så att kompromettering av långsiktiga nycklar inte exponerar tidigare sessioner.
• Prestanda på begränsad hårdvara: Mindre nyckelstorlekar minskar direkt beräkningskostnaden för kryptografiska operationer, vilket gör ECC till det praktiska valet för mobila enheter, IoT-sensorer och smartkort.

Nackdelar med ECC

• Kurvvalet är avgörande: ECC-säkerhet är starkt beroende av att välja matematiskt sunda kurvparametrar. Svaga eller dåligt valda kurvor kan introducera sårbarheter som undergräver säkerhetsgarantierna. Använd endast NIST-standardiserade kurvor (P-256, P-384, P-521) eller allmänt granskade alternativ (X25519, Ed25519).
• Inte kvantsäker: Shors algoritm på en kvantdator bryter mot ECDLP. ECC måste migreras till postkvantalgoritmer (ML-KEM, ML-DSA) för långlivad infrastruktur.
• Kompatibilitetsluckor från äldre system: Äldre system, inbyggda enheter och viss mellanprogramvara för företag kanske inte stöder ECC. RSA-kompatibilitet är bredare för äldre brownfield-miljöer.
• Implementeringskomplexitet: ECC-implementeringar måste hantera kantfall i kurvaritmetik (point-at-infinity, validering av ogiltig publik nyckel) noggrant för att undvika sårbarheter i sidokanalerna. Använd väl testade kryptografiska bibliotek snarare än anpassade implementeringar.

Tillämpningar av elliptisk kurvkryptografi

1. Digitala signaturer och kodsignering: ECDSA signerar dokument, programvaruversioner och firmwareuppdateringar för att verifiera äkthet och upptäcka manipulering. Mindre signaturer och snabbare signering gör det att föredra framför RSA för kodsigneringspipelines med hög genomströmning.
2. Säkra webbanslutningar (HTTPS/TLS): ECDSA P-256 TLS-certifikat autentiserar servrar. ECDHE tillhandahåller utbyte av framåtriktade hemliga nyckelringar under TLS-handskakningen. Mindre ECC-certifikat minskar tiden för anslutningsupprättande, vilket särskilt gynnar mobila anslutningar och anslutningar med låg bandbredd.
3. SSH-nyckelautentisering: Ed25519 är den för närvarande föredragna algoritmen för SSH-nycklar, och ger kompakta 32-byte publika nycklar, snabba operationer och motståndskraft mot tidsinställda sidokanalattacker. Se vårt inlägg om SSH nyckelhantering för vägledning för utplacering.
4. Kryptovalutor och blockkedja: ECDSA (främst secp256k1 för Bitcoin och Ethereum) säkrar nyckelpar för plånböcker och transaktionssignaturer. Den kompakta nyckelstorleken är särskilt viktig för effektiviteten i blockkedjeutrymmet.
5. IoT-enhetssäkerhet: ECC:s små nyckelstorlekar och låga beräkningskostnader gör den till det praktiska valet för IoT-sensorer, smarta mätare och inbyggda system med begränsad processorkraft och batteritid.
6. Nyckelutbyte för krypterad kommunikation: ECDH och ECDHE används i meddelandeapplikationer (Signal Protocol använder X25519), e-postkryptering och VPN-protokoll för att upprätta delade sessionsnycklar utan att överföra hemligheter.

Implementeringsexempel: ECC i en produktionsmiljö för TLS och kodsignering

Ett mjukvaruföretag distribuerar ECC över sin TLS-certifikatinfrastruktur och kodsigneringspipeline:

1. Migrering av TLS-certifikat: Befintliga RSA-2048 TLS-certifikat på publika webbservrar ersätts med ECDSA P-256-certifikat. Certifikatstorleken minskar från cirka 1 200 byte till 400 byte, vilket minskar antalet TLS-handskakningsbyte som utväxlas och förbättrar tiden det tar att etablera en anslutning på mobilnät.
2. TLS-serverkonfiguration: Servrar är konfigurerade för att stödja TLS 1.3 med ECDHE X25519 som föredraget nyckelutbyte. Vidarebefordran av sekretess är nu obligatorisk för alla anslutningar; tidigare sessioner kan inte dekrypteras även om den privata ECDSA-nyckeln senare komprometteras.
3. Kodsigneringsrörledning: CodeSign Secure signerar alla programvaruversioner med ECDSA P-256. Signeringsnycklar lagras i FIPS 140-3-validerade HSM, vilket säkerställer att den privata nyckeln aldrig hamnar i applikationens minne. ECDSA-signaturstorleken är cirka 64 byte, jämfört med 384 byte för RSA-3072, vilket minskar overhead för signerade artefakter.
4. Intern tjänstautentisering: Tjänst-till-tjänst-kommunikation använder ömsesidig TLS (mTLS) med ECDSA P-256-certifikat utfärdade av en intern CA. Korta certifikatlivslängder (90 dagar, hanteras av CertSecure-hanterare) begränsa exponeringsfönstret om ett certifikat komprometteras.
5. PQC-migreringsplanering: företaget använder CBOM-säkerhet att inventera alla distribuerade ECC-instanser. Långlivade privata nycklar från CA och kodsigneringsinfrastruktur identifieras som de första migreringskandidaterna för ML-DSA (FIPS 204) före NIST-utfasningens tidslinje 2030.

Nyckelhantering för ECC

• Privat nyckellagring: Privata ECC-nycklar måste lagras i FIPS 140-2 nivå 2 eller högre HSM-hårdvara för CA-nycklar, kodsigneringsnycklar och andra nycklar med lång livslängd och hög effekt. HSM:er säkerställer att kryptografiska operationer sker inuti manipulationssäker hårdvara; den privata nyckeln hamnar aldrig i applikationsminnet på en server som kan komprometteras.
• Nonce-generering (k-värde) i ECDSA: ECDSA-signering kräver ett unikt, slumpmässigt nonce-värde k för varje signatur. Om k återanvänds mellan två signaturer med samma privata nyckel kan den privata nyckeln beräknas algebraiskt från de två signaturerna. Denna sårbarhet utnyttjades i uppmärksammade attacker mot hårdvaruenheter. Använd deterministisk ECDSA (RFC 6979) eller hårdvarugenererade nonce-värden för att eliminera denna risk.
• Automatisering av certifikatlivscykeln: Med tanke på att CA/Browser Forum föreskriver att TLS-certifikat ska ha en livslängd på så korta som 47 dagar år 2029, är manuell certifikathantering inte genomförbar i stor skala. Automatiserad hantering av certifikatlivscykeln krävs för alla ECC TLS-certifikat. Se CertSecure-hanterare för automatiserad identifiering, förnyelse och policytillämpning.

Krypteringskonsultföretagets CodeSign Secure

CodeSign Secure hjälper programvaruorganisationer att bygga förtroende hos slutanvändare genom att säkerställa äktheten och integriteten hos programvaruversioner med hjälp av ECC. Mer specifikt använder CodeSign Secure ECDSA med nyckeltyper inklusive P-256 och P-384 för att skapa digitala signaturer som verifierar att programvaran inte har modifierats sedan den signerades. Viktiga funktioner relevanta för ECC-distribution:

• HSM-baserad nyckellagring: Privata nycklar för signering lagras i FIPS 140-3-validerade HSM:er (som stöder PKCS#11- och FIPS 140-3-standarder), vilket säkerställer att privata ECC-nycklar aldrig lämnar manipulationssäker hårdvara.
• CI/CD-pipelineintegration: automatiserar signeringsarbetsflöden inom Jenkins, Azure DevOps, GitHub Actions och andra plattformar, vilket eliminerar manuella signeringssteg som introducerar mänskliga fel och förseningar.
• Revisionslogg och efterlevnadsrapportering: Detaljerad loggning av varje signeringsoperation stöder efterlevnadskrav och ger bevis för granskningar av kodsigneringspolicyer.
• Algoritmstyrning: framtvingar att endast godkända ECC-kurvor och hashalgoritmer används för signering, vilket förhindrar att utvecklare använder svaga parametrar som standard.

Begränsningar med ECC

• Inte kvantsäker: Shors algoritm bryter ECDLP på en kvantdator. Detta är den viktigaste begränsningen för långlivad infrastruktur. NIST föreslår att ECC avvecklas efter 2030 enligt NIST IR 8547. Börja planeringen av PQC-migrering nu för certifikathierarkier och kodsigneringsnycklar.
• Kurvvalet är avgörande: Säkerheten beror på de matematiska egenskaperna hos den valda kurvan. Använd endast standardiserade kurvor: NIST P-256, P-384, P-521, X25519 eller Ed25519. Implementera inte anpassade kurvor eller parametrar.
• ECDSA nonce-säkerhetskrav: deterministisk ECDSA (RFC 6979) måste användas för att eliminera risken för återanvändning vid engångsbruk, vilket skulle exponera den privata nyckeln. Detta är en känd implementeringsfallgrop som har äventyrat implementeringar i verkliga situationer.
• Begränsningar för äldre kompatibilitet: Vissa äldre system, inbyggda enheter och mellanprogramvara för företag stöder inte ECC. Miljöer som kräver maximal kompatibilitet med äldre system kan fortfarande behöva RSA under en övergångsperiod.

Slutsats

Elliptisk kurvkryptografi är den föredragna asymmetriska kryptografiska algoritmen för de flesta nya implementeringar tack vare dess kombination av stark säkerhet, små nyckelstorlekar, snabba operationer och låga resurskrav. ECDSA P-256 och Ed25519 är de NIST-rekommenderade valen för digitala signaturer och TLS; ECDHE tillhandahåller det obligatoriska utbytet av hemliga nyckelringar i TLS 1.3. ECC är inbäddat i TLS 1.3, FIDO2, SSH, S/MIME, kodsignering och de flesta moderna säkerhetsprotokoll.

Den kritiska varningen: ECC är inte kvantsäker. Shors algoritm bryter mot ECDLP. För infrastruktur med nyckellivslängder på flera år, inklusive CA-privata nycklar, kodsigneringsinfrastruktur och långlivade TLS-hierarkier, måste organisationer börja planera PQC-migrering nu. NIST har standardiserat ML-KEM (FIPS 203) och ML-DSA (FIPS 204) som ersättare efter kvantum. För relaterad läsning, se våra inlägg om symmetrisk vs. asymmetrisk kryptering och jämförelse av krypteringsalgoritmer.

Vanliga frågor om partihandel med mat och dryck

Vad är elliptisk kurvkryptering (ECC)?

ECC är ett kryptografiskt system med publik nyckel baserat på elliptiska kurvor över ändliga fält, definierade av y² = x³ + ax + b. Dess säkerhet bygger på ECDLP (Elliptic Curve Discrete Logarithm Problem), som inte har någon känd subexponentiell lösning på väl valda kurvor. En 256-bitars ECC-nyckel ger ungefär 128-bitars säkerhet, motsvarande RSA-3072. Föreslagen av Neal Koblitz och Victor S. Miller 1985.

Vad är skillnaden mellan ECDH och ECDSA?

ECDH (Elliptic Curve Diffie-Hellman) är ett nyckelutbytesprotokoll som upprättar en delad hemlighet mellan två parter utan att överföra den. ECDHE (ephemeral) tillhandahåller framåtriktad sekretess; TLS 1.3 kräver det för alla anslutningar. ECDSA (Elliptic Curve Digital Signature Algorithm) är en signaturalgoritm som använder privata nycklar för att signera data och publika nycklar för att verifiera signaturer. Används i TLS-certifikat, kodsignering och SSH-autentisering.

Hur står sig ECC i jämförelse med RSA?

ECC P-256 ger 128-bitars säkerhet med en 32-byte nyckel; RSA behöver 3072 bitar för motsvarande säkerhet. ECDSA-signering är snabbare än RSA-signering vid motsvarande säkerhetsnivåer. ECC-certifikat är ungefär en tredjedel så stora som RSA-certifikat. Ingetdera är kvantsäkert; båda kräver migrering till postkvantalgoritmer (ML-KEM, ML-DSA).

Vilka ECC-kurvor rekommenderas av NIST?

NIST FIPS 186-5 specificerar: P-256 (128-bitars säkerhet, mest spridda), P-384 (192-bitars, hemlig nivå), P-521 (256-bitars, topphemlig). X25519 och Ed25519 är godkända alternativ med brett stöd: X25519 för TLS 1.3-nyckelutbyte; Ed25519 som den föredragna SSH-nyckelalgoritmen.

Är ECC kvantsäkert?

Nej. Shors algoritm på en kvantdator löser effektivt ECDLP och bryter all ECC-baserad kryptografi. NIST har standardiserade post-kvantum-ersättningar: ML-KEM (FIPS 203) för nyckelutbyte och ML-DSA (FIPS 204) för signaturer. NIST IR 8547 föreslår att ECC avskrivs efter 2030 och förbjuds efter 2035 i nya applikationer.

När ska ECC användas istället för RSA?

För alla nya implementeringar utan äldre begränsningar: TLS-certifikat (ECDSA P-256), SSH-nycklar (Ed25519), kodsignering (ECDSA P-256 eller P-384), DNSSEC, mobil och IoT. Använd RSA endast där ECC inte stöds av äldre system eller specifika efterlevnadskrav kräver det.