768-bitars RSA-nyckel faktoriserad

0 kommentarer

Bruce Schneier har en kort notis i sitt senaste nyhetsbrev, Crypto-Gram, om att en grupp forskare lyckats faktorisera en 768-bitars RSA-nyckel. Med hjälp av en distribuerad datorkraft bestående av hundratals processorer som arbetade i knappt tre år lyckades man visa att heltalet:

12301866845301177551304949583849627207728535695953347921973224521517

26400507263657518745202199786469389956474942774063845925192557326303

45373154826850791702612214291346167042921431160222124047927473779408

0665351419597459856902143413

är en produkt av primtalen

33478071698956898786044169848212690817704794983713768568912431388982

883793878002287614711652531743087737814467999489

och

36746043666799590428244633799627952632279158164343087642676032283815

739666511279233373417143396810270092798736308917

Skrivet på ett mer abstrakt algebraiskt vis så består en RSA-nyckel av ett heltal, N, som är en produkt av två primtal, P och Q, dvs N = P*Q. Det går relativt snabbt att skapa en RSA-nyckel genom att slumpa fram två primtal och multiplicera dem för att bilda N, som är den publika nyckeln som man kan sprida till alla sina kontakter, gärna i form av ett certifikat. Den privata RSA-nyckeln, som det gäller att hålla hemlig (exempelvis genom att lagra den på ett smart kort) består av de två primtalen P och Q. För att forcera en publik RSA-nyckel kan man alltså försöka "dela upp" N i sina beståndsdelar P och Q. Denna process kallas faktorisering och det är alltså vad forskarna har lyckats med för ett heltal i storleksordningen 2768, vilket motsvarar 232 decimala siffror (kontrollräkna gärna på heltalet ovan den som orkar). Ju större heltal (dvs ju fler bitar eller siffror som ingår i heltalet), desto längre tid tar det att faktorisera det. Därför måste RSA-nycklar bestå av heltal med tusentals bitar (motsvarande över 300 decimala siffror).

Bruce's blogginlägg om detta citerar ordagrant från forskarnas artikel:

(På svenska:) "Eftersom det är tio år sedan en 512-bitars RSA-nyckel först faktoriserades är det inte otroligt att 1024-bitars RSA-nycklar kommer att kunna faktoriseras inom det närmsta decenniet". Således rekommenderar forskarna att "det skulle vara klokt att fasa 1024-bitars RSA nycklar inom de närmaste 3-4 åren".

Det är naturligt att man måste bevaka utvecklingen inom kryptoanalys och ständigt öka nyckellängden för att hålla en rimlig säkerhetsnivå. Redan idag rekommenderas exempelvis att nyckellängden för utfärdare av certifikat (CA) bör vara minst 2048 bitar.

Betyder då det här att man snarast måste ersätta alla 1024-bitars nycklar?

Nja, det är lite vanskligt att resonera om riskerna för 1024-bitars nycklar givet att man lyckats faktorisera en 768-bitars nyckel. Först och främst bör man tänka på att för varje (slumpad) bit som man lägger till nyckellängden så fördubblas svårigheten att forcera den. Nu är i och för sig detta inte helt sant. Den snabbaste faktoriseringsalgoritmen man känner till (GNFS) är något snabbare än exponentiell tid.

Det kan vara upplysande att fundera på vad vi skulle göra idag om vi hade RSA-nycklar på 768 bitar. Fortfarande är det ju så att en lyckad forcering tycks kräva ett par års arbete av ett hundratal processorer som är sammankopplade i ett nätverk. Det ger lite respit. Risken är att någon bestämmer sig för att attackera just vår nyckel och sedan ser till att skaffa fram den nödvändiga utrustningen i form av processorer och programvara (GNFS är en extremt komplicerad algoritm). Även om alla dessa villkor är uppfyllda lär det ändå dröja ett par år innan vår nyckel blivit röjd.

Notera att om vi endast använder vår 768-bitarsnyckel för att legitimera oss och logga in i datorsystem så kan vi skydda oss genom att helt enkelt byta nyckel en gång per år.

Vilken risk löper vi då om vi använder 768-bitarsnyckeln för elektroniska underskrifter? Tja, så länge vi ser till att tidsstämpla de elektroniskt undertecknade dokumenten (naturligtvis med en nyckel som innehåller fler bitar) så kan vi faktiskt även hantera den situationen. Vi bör även i detta fall se till att byta nycklar en gång per år. Om vi inte tidsstämplar dokumenten kan vi dock få problem. Man vill ju i regel att en elektronisk underskrift ska vara giltig under en längre tid och i det här fallet går det inte att garantera.

Det största problemet uppstår dock om vi vill använda vår 768-bitarsnyckel för att kryptera känslig information. Efter ett par år kan vi inte längre vara säkra på att den krypterade informationen fortfarande är hemlig. Någon kan ha röjt vår nyckel och dekrypterat informationen. Mot bakgrund av detta rekommenderar jag att RSA-nycklar som ska användas för kryptering bör vara mer än 1024 bitar långa.

Kanske börjar det ändå snart vara dags att på allvar börja överväga att införa nycklar baserade på elliptiska kurvor (ECC = Elliptic Curve Cryptography) i stället för att bara öka nyckellängden för RSA-nycklarna.

Jag brukar annars sällan rekommendera användning av baserade på elliptiska kurvor av den enkla anledningen att det är för få system som stödjer det ännu. I regel vill man ju ha en lösning som fungerar mellan så många system och användare som möjligt och då är RSA fortfarande helt överlägset. Med elliptiska kurvor kan man emellertid erhålla en högre säkerhetsnivå med kortare nycklar. En ECC-nyckel på 160 bitar sägs vara ungefär lika svårforcerad som en RSA-nyckel på 1024 bitar. Även 160 bitar är dock för mycket för en människa att hålla i huvudet (i Base64 skulle det bli 27 tecken) så det är förmodligen inte en tillräckligt stor vinst att gå över till ECC bara för att minska nyckelländen.


 

Jag tänkte avsluta med en liten anekdot om faktorisering, där både Bruce Schneier och Simon Singh, en av mina favoritförfattare när det gäller populärvetenskap, figurerar.

Simon Singh gjorde succé med den osannolika bestsellern Fermats gåta, som handlar om hur matematikern Andrew Wiles 1995 lyckades bevisa Fermats stora sats. Uppföljaren, som kom ut 1999, var en bok om kryptografins historia som lite fyndigt döptes till Kodboken. Norstedts förlag anordnade ett seminarium med Simon Singh i samband med lanseringen av Kodboken på svenska. Vi var väl ett tjugotal åhörare som hade bänkat oss för att få oss till livs en intressant exposé om kampen mellan kodskapare och kodknäckare alltsedan Maria Stuarts 1500-tal fram till dagens moderna kvantkrypteringsmetoder.

Nu visade det sig att en av åhörarna som dök upp var ingen mindre än Bruce Schneier himself, med både skägg och kryptopiska precis som man tänker sig honom. Schneier var i Stockholm i ett helt annat ärende, vill minnas att han skulle tala vid något större seminarium senare på helgen, och hade en eftermiddag att slå ihjäl. Så i stället för att sitta på hotellrummet och häcka valde han att gå och lyssna på när Simon Singh la ut texten om kryptografins historia.

Bruce Schneier är en erkänt skicklig kodskapare, i synnerhet när det gäller symmetriska chiffer (bl.a. Blowfish och Twofish). Mest känd är han dock kanske som en slags journalist inom krypto och säkerhet. Efter 11 september 2001 har han mest fått uttala sig om flygplatssäkerhet, terrorism och liknande, med skarpsinniga och sansade åsikter som så väl behövs i USA idag.

Simon Singh å andra sidan doktorerade i partikelfysik innan han började på BBC som vetenskapsreporter. Som kryptolog är han dock väldigt okänd (vilket emellertid inte hindrar honom från att skriva en bra bok om kryptografins historia).

Hur som helst, det märktes på Simon att han blev rätt nervös när han upptäckte att Bruce Schneier satt i publiken. Det är väl ungefär som att föreläsa om kosmologi för, tja, Stephen Hawking. I alla fall nästan. Bruce höll dock en relativt låg profil och gjorde bara ett par inlägg på direkt uppmaning av Simon. Jag minns dock ingenting av vad det var han sa men det var säkert något vettigt.

Vad har då detta med faktorisering att göra? Jo, längst bak i Kodboken hade Simon Singh lagt in en utmaning (Crypto Challenge) i form av tio krypterade meddelanden som man skulle forcera. Simon Singh tillkännagav att den första som lyckades lösa alla chiffer skulle vinna ett pris på 10 000 pund. Problemen var ordnade i svårighetsgrad där de första kunde lösas med papper och penna. Det tionde och sista chiffret var krypterat med en 512-bitars RSA-nyckel.

Simon Singh hade nog tänkt att det skulle bli en nöt som skulle hålla läsekretsen sysselsatt ett bra tag. Faktorisering av 512-bitars RSA-nycklar var det yttersta frontlinjen vid denna tid. Redan efter ett år och en månad lyckades dock ett svenskt lag, mestadels bestående av doktorander vid KTH, presentera lösningar på alla tio uppgifter. Läs den om den rafflande historien på Simon Singhs egen websida eller vinnarlagets egen berättelse!

Nytt verktyg för att testa SSL-TLS (OWASP-CM-001): SSLAudit

3 kommentarer
SSLAudit är ett verktyg för att verifierar SSL certifikat och vilka protokoll och krypteringsalgoritmer som stöds av en HTTPS-webbserver. Resultatet betygsätts enligt SSLLabs SSL Server Rating Guide. Jag (Michael Boman) skapade SSLAudit för jag saknade ett bra verktyg för att verifiera HTTPS-servrar (OWASP-CM-001). Det finns flera verktyg som kan testa HTTPS-servrar, men de uppfyllde inte mina krav:
  • SSLDigger från Foundstone (som inte får användas i kommersiella syften, dvs. inte av konsulter på uppdrag) och THCSSLCheck från The Hacker’s Choice: båda är proprietär programvara utan källkod och är svåra att uppdatera. SSLDigger har inte uppdaterats sedan 2004 och THCSSLCheck var senast uppdaterad 2006.
  • SSLScan (med tillhörande perl modul) är öppen källkod har mycket liknande funktionalitet och kan fungera för dig, men det kan inte betygsätta resultatet (vilket inte är svårt att lägga till genom den perl modul som finns) och jag hade problem att få den fungera på Windows/Cygwin.
  • SSLLabs har även en online tjänst för att skanna och betygsätta publika HTTPS-webbsajter, men fungerar inte på interna nätverk.
SSLAudit uppfyller mina krav. Verktyget är öppen källkod, licensierat enligt GPL 2.0, och vilka protokoll och krypteringsalgoritmer konfigureras enkelt via en .INI textfil. SSLAudit funkar fint på både Windows och Linux, och använder sig av standard CPAN moduler. Just nu rapporterar den bara resultatet till terminalfönstret, men det finns planer för att kunna skapa HTML-rapporter.

Användarinstruktioner:
sslaudit.pl website [port]
Exempel:
$> perl sslaudit.pl www.google.com

Connecting to www.google.com:443 - OK
Certificate CN: www.google.com == Hostname: www.google.com
Subject Name: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
Issuer Name: /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA

-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA6PmGD5D6htffvXImttdEAoN4c9kCKO+IRTn7EOh8rqk41XXGOOsKFQebg+jN
gtXj9xVoRaELGYW84u+E593y17iYwqG7tcFR39SDAqc9BkJb4SLD3muFXxzW2k6L
05vuuWciKh0R73mkszeK9P4Y/bz5RiNQl/Os/CRGK1w7t0UCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5
u2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6
z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw==
-----END CERTIFICATE-----

Valid from: Dec 18 00:00:00 2009 GMT
Valid to: Dec 18 23:59:59 2011 GMT
Certificate date valid


SSLv2 - DEFAULT - unsuccessful
SSLv2 - RC4-MD5 - unsuccessful
SSLv2 - EXP-RC4-MD5 - unsuccessful
SSLv2 - RC2-MD5 - unsuccessful
SSLv2 - EXP-RC2-MD5 - unsuccessful
SSLv2 - IDEA-CBC-MD5 - unsuccessful
SSLv2 - DES-CBC-MD5 - unsuccessful
SSLv2 - DES-CBC3-MD5 - unsuccessful


SSLv2 not supported by server


SSLv3 - DEFAULT - successful - 80
SSLv3 - NULL-MD5 - unsuccessful
SSLv3 - NULL-SHA - unsuccessful
SSLv3 - EXP-RC4-MD5 - unsuccessful
SSLv3 - RC4-MD5 - successful - 80
SSLv3 - RC4-SHA - successful - 80
SSLv3 - EXP-RC2-CBC-MD5 - unsuccessful
SSLv3 - IDEA-CBC-SHA - unsuccessful
SSLv3 - EXP-DES-CBC-SHA - unsuccessful
SSLv3 - DES-CBC-SHA - unsuccessful
SSLv3 - DES-CBC3-SHA - successful - 80
SSLv3 - EXP-EDH-DSS-DES-CBC-SHA - unsuccessful
SSLv3 - EDH-DSS-CBC-SHA - unsuccessful
SSLv3 - EDH-DSS-DES-CBC3-SHA - unsuccessful
SSLv3 - EXP-EDH-RSA-DES-CBC-SHA - unsuccessful
SSLv3 - EDH-RSA-DES-CBC-SHA - unsuccessful
SSLv3 - EDH-RSA-DES-CBC3-SHA - unsuccessful
SSLv3 - EXP-ADH-RC4-MD5 - unsuccessful
SSLv3 - ADH-RC4-MD5 - unsuccessful
SSLv3 - EXP-ADH-DES-CBC-SHA - unsuccessful
SSLv3 - ADH-DES-CBC-SHA - unsuccessful
SSLv3 - ADH-DES-CBC3-SHA - unsuccessful
SSLv3 - EXP1024-DES-CBC-SHA - unsuccessful
SSLv3 - EXP1024-RC4-SHA - unsuccessful
SSLv3 - EXP1024-DHE-DSS-DES-CBC-SHA - unsuccessful
SSLv3 - EXP1024-DHE-DSS-RC4-SHA - unsuccessful
SSLv3 - DHE-DSS-RC4-SHA - unsuccessful


SSLv3 cipher score: 80 (A)


TLSv1 - DEFAULT - successful - 90
TLSv1 - NULL-MD5 - unsuccessful
TLSv1 - NULL-SHA - unsuccessful
TLSv1 - EXP-RC4-MD5 - unsuccessful
TLSv1 - RC4-MD5 - successful - 80
TLSv1 - RC4-SHA - successful - 80
TLSv1 - EXP-RC2-CBC-MD5 - unsuccessful
TLSv1 - IDEA-CBC-SHA - unsuccessful
TLSv1 - EXP-DES-CBC-SHA - unsuccessful
TLSv1 - DES-CBC-SHA - unsuccessful
TLSv1 - DES-CBC3-SHA - successful - 80
TLSv1 - EXP-EDH-DSS-DES-CBC-SHA - unsuccessful
TLSv1 - EDH-DSS-CBC-SHA - unsuccessful
TLSv1 - EDH-DSS-DES-CBC3-SHA - unsuccessful
TLSv1 - EXP-EDH-RSA-DES-CBC-SHA - unsuccessful
TLSv1 - EDH-RSA-DES-CBC-SHA - unsuccessful
TLSv1 - EDH-RSA-DES-CBC3-SHA - unsuccessful
TLSv1 - EXP-ADH-RC4-MD5 - unsuccessful
TLSv1 - ADH-RC4-MD5 - unsuccessful
TLSv1 - EXP-ADH-DES-CBC-SHA - unsuccessful
TLSv1 - ADH-DES-CBC-SHA - unsuccessful
TLSv1 - ADH-DES-CBC3-SHA - unsuccessful
TLSv1 - AES128-SHA - successful - 80
TLSv1 - AES256-SHA - successful - 100
TLSv1 - DHE-DSS-AES128-SHA - unsuccessful
TLSv1 - DHE-DSS-AES256-SHA - unsuccessful
TLSv1 - DHE-RSA-AES128-SHA - unsuccessful
TLSv1 - DHE-RSA-AES256-SHA - unsuccessful
TLSv1 - ADH-AES128-SHA - unsuccessful
TLSv1 - ADH-AES256-SHA - unsuccessful
TLSv1 - CAMELLIA128-SHA - unsuccessful
TLSv1 - CAMELLIA256-SHA - unsuccessful
TLSv1 - DHE-DSS-CAMELLIA128-SHA - unsuccessful
TLSv1 - DHE-DSS-CAMELLIA256-SHA - unsuccessful
TLSv1 - DHE-RSA-CAMELLIA128-SHA - unsuccessful
TLSv1 - DHE-RSA-CAMELLIA256-SHA - unsuccessful
TLSv1 - ADH-CAMELLIA128-SHA - unsuccessful
TLSv1 - ADH-CAMELLIA256-SHA - unsuccessful
TLSv1 - ADH-SEED-SHA - unsuccessful


TLSv1 cipher score: 90 (A)


TLSv11 - DEFAULT - successful - 95
TLSv11 - NULL-MD5 - unsuccessful
TLSv11 - NULL-SHA - unsuccessful
TLSv11 - EXP-RC4-MD5 - unsuccessful
TLSv11 - RC4-MD5 - successful - 80
TLSv11 - RC4-SHA - successful - 80
TLSv11 - EXP-RC2-CBC-MD5 - unsuccessful
TLSv11 - IDEA-CBC-SHA - unsuccessful
TLSv11 - EXP-DES-CBC-SHA - unsuccessful
TLSv11 - DES-CBC-SHA - unsuccessful
TLSv11 - DES-CBC3-SHA - successful - 80
TLSv11 - EXP-EDH-DSS-DES-CBC-SHA - unsuccessful
TLSv11 - EDH-DSS-CBC-SHA - unsuccessful
TLSv11 - EDH-DSS-DES-CBC3-SHA - unsuccessful
TLSv11 - EXP-EDH-RSA-DES-CBC-SHA - unsuccessful
TLSv11 - EDH-RSA-DES-CBC-SHA - unsuccessful
TLSv11 - EDH-RSA-DES-CBC3-SHA - unsuccessful
TLSv11 - EXP-ADH-RC4-MD5 - unsuccessful
TLSv11 - ADH-RC4-MD5 - unsuccessful
TLSv11 - EXP-ADH-DES-CBC-SHA - unsuccessful
TLSv11 - ADH-DES-CBC-SHA - unsuccessful
TLSv11 - ADH-DES-CBC3-SHA - unsuccessful
TLSv11 - AES128-SHA - successful - 80
TLSv11 - AES256-SHA - successful - 100
TLSv11 - DHE-DSS-AES128-SHA - unsuccessful
TLSv11 - DHE-DSS-AES256-SHA - unsuccessful
TLSv11 - DHE-RSA-AES128-SHA - unsuccessful
TLSv11 - DHE-RSA-AES256-SHA - unsuccessful
TLSv11 - ADH-AES128-SHA - unsuccessful
TLSv11 - ADH-AES256-SHA - unsuccessful
TLSv11 - CAMELLIA128-SHA - unsuccessful
TLSv11 - CAMELLIA256-SHA - unsuccessful
TLSv11 - DHE-DSS-CAMELLIA128-SHA - unsuccessful
TLSv11 - DHE-DSS-CAMELLIA256-SHA - unsuccessful
TLSv11 - DHE-RSA-CAMELLIA128-SHA - unsuccessful
TLSv11 - DHE-RSA-CAMELLIA256-SHA - unsuccessful
TLSv11 - ADH-CAMELLIA128-SHA - unsuccessful
TLSv11 - ADH-CAMELLIA256-SHA - unsuccessful
TLSv11 - ADH-SEED-SHA - unsuccessful


TLSv11 cipher score: 90 (A)


TLSv12 - DEFAULT - successful - 100
TLSv12 - NULL-MD5 - unsuccessful
TLSv12 - NULL-SHA - unsuccessful
TLSv12 - EXP-RC4-MD5 - unsuccessful
TLSv12 - RC4-MD5 - successful - 80
TLSv12 - RC4-SHA - successful - 80
TLSv12 - EXP-RC2-CBC-MD5 - unsuccessful
TLSv12 - IDEA-CBC-SHA - unsuccessful
TLSv12 - EXP-DES-CBC-SHA - unsuccessful
TLSv12 - DES-CBC-SHA - unsuccessful
TLSv12 - DES-CBC3-SHA - successful - 80
TLSv12 - EXP-EDH-DSS-DES-CBC-SHA - unsuccessful
TLSv12 - EDH-DSS-CBC-SHA - unsuccessful
TLSv12 - EDH-DSS-DES-CBC3-SHA - unsuccessful
TLSv12 - EXP-EDH-RSA-DES-CBC-SHA - unsuccessful
TLSv12 - EDH-RSA-DES-CBC-SHA - unsuccessful
TLSv12 - EDH-RSA-DES-CBC3-SHA - unsuccessful
TLSv12 - EXP-ADH-RC4-MD5 - unsuccessful
TLSv12 - ADH-RC4-MD5 - unsuccessful
TLSv12 - EXP-ADH-DES-CBC-SHA - unsuccessful
TLSv12 - ADH-DES-CBC-SHA - unsuccessful
TLSv12 - ADH-DES-CBC3-SHA - unsuccessful
TLSv12 - AES128-SHA - successful - 80
TLSv12 - AES256-SHA - successful - 100
TLSv12 - DHE-DSS-AES128-SHA - unsuccessful
TLSv12 - DHE-DSS-AES256-SHA - unsuccessful
TLSv12 - DHE-RSA-AES128-SHA - unsuccessful
TLSv12 - DHE-RSA-AES256-SHA - unsuccessful
TLSv12 - ADH-AES128-SHA - unsuccessful
TLSv12 - ADH-AES256-SHA - unsuccessful
TLSv12 - CAMELLIA128-SHA - unsuccessful
TLSv12 - CAMELLIA256-SHA - unsuccessful
TLSv12 - DHE-DSS-CAMELLIA128-SHA - unsuccessful
TLSv12 - DHE-DSS-CAMELLIA256-SHA - unsuccessful
TLSv12 - DHE-RSA-CAMELLIA128-SHA - unsuccessful
TLSv12 - DHE-RSA-CAMELLIA256-SHA - unsuccessful
TLSv12 - ADH-CAMELLIA128-SHA - unsuccessful
TLSv12 - ADH-CAMELLIA256-SHA - unsuccessful
TLSv12 - ADH-SEED-SHA - unsuccessful


TLSv12 cipher score: 90 (A)


Protocol score: 90 (A)

Tillgänglighet:
SSLAudit kan laddas ner från Google Code project hosting, där det även finns funktionalitet för att rapportera eventuella buggar och önskade förbättringar.

/Michael Boman

Hur lång giltighetstid ska CA certifikat ha?

0 kommentarer
Ett certifikat (elektronisk legitimation) har en viss giltighetstid. Beroende hur lång tid man vill ha, måste utgivaren kallad Certificate Authority (CA) ha en längre giltighetstid på sitt certifikat.

Många PKI-miljöer och CA:s är (för)konfigurerade för att hantera utgivna certifikat som bara är giltiga ett eller två år innan de ska förnyas. Det kan gälla maskincertifikat eller användarcertifikat (mjuka på fil eller hårda på smarta kort).

Fler och fler organisationer börjar nu kombinera smarta kort och SIS-godkända legitimationer. Ett SIS-kort gäller i fem år, sedan måste ett nytt kort beställas. Det kan då för enkelhetens skull vara bra att även ha ett certifikat som gäller i fem år på samma kort.

Problem 1: Att alltid få rätt giltighetstid
Säg att vi har en CA som utfärdar användarcertifikat. När man utfärdar ett certifikat med en giltighetstid på fem år måste CA:ns certifikat alltid vara giltig minst lika länge. Annars får det utfärdade certifikatet en kortare giltighetstid, ty det kan inte vara längre än CA:ns. Detta är en begränsning i Microsoft CA. Enligt X.509 standarden ( http://www.ietf.org/rfc/rfc5280.txt ) är det tillåtet, men då går det ju inte att verifiera certifikatskedjan.

I vårt exempel måste alltså sub CA certifikatet vara giltigt i 10 år. Detta gör att man kan skapa 5-åriga användarcertifikat när som helst under de första 5 åren på en sub CA:s giltighetstid.

Problem 2: 6-årsdagen
Efter att CA certifikatet passerat sin 5-årsdag blir det problem. Om man år 6 försöker utfärda ett 5-årigt certifikat, då är det ju bara 4 år kvar på CA:ns giltighetstid och kan därför bara utfärda max 4-åriga certifikat.

Lösningen är att förnya CA certifikatet efter halva giltighetstiden, alltså efter 5 år. Det nya CA certifikatet får en ny giltighetstid på 10 år.

Root CA
Säg att vi även har en root CA. Denna bör då analogt ha dubbla giltighetstiden jämfört med sin sub CA och ska också förnyas efter halva tiden.

1. Root CA (20 år)
2. Sub CA (10 år)
3. Användarcertifikat (5 år)

Varje utfärdande CA måste få sitt eget certifikat förnyat efter halva tiden. Det är okej att göra det oftare, men aldrig mer sällan.

I ovanstående fall ska sub CA:n förnyas vart 5:e år. Eller kanske efter 4 år och 10 månader för att inte vara ute i sista stund med risk att man drar över tiden. De kan vara lämpligt att alltid förnya root CA:n vid samma tidpunkt, så att man inte missar det någon gång.

Vissa organisationer har en root CA på 20 år och har ingen rutin att förnya den, med argument att PKI-miljön aldig kommer leva så länge. Tänk bara på hur många legacysystem som finns idag? Genom att förnya root CA certifikatet vart 5:e år så hanteras det oavsett hur länge miljön lever.

Uppdaterar man inte CA certifkaten rätt och i tid, går det inte validera hela certifikatskedjan och användaren/maskinen ges inte access.

Konfigurera rätt
Tänk på att CA applikationen måste anpassas för de förlängda giltighetstiderna. Microsoft CA sätter dessa tider i mallar samt har en global inställning i registret som anger maxtiden på ett utgivet certifikat (default 2 år). Många timmar i felsökning kan gå åt om man inte känner till detta. Se även http://support.microsoft.com/kb/254632

Glöm inte lägga in alla förnyade CA certifikat i Trusted Roots.

/Anders Helgesson

IT säkerhet från skyttegraven- Del 1

0 kommentarer
Hej kära säkerhetsintresserade läsare. Mitt namn är Peter Swedin, jag har förmånen att arbeta tillsammans med några av Sveriges vassaste nätverks- och infrastruktursäkerhetsexperter på Omegapoint. Eftersom det är hjärtefrågan tänkte jag skriva några rader om detta område och de utmaningar som vårt team ofta möter. Hur hanterar vi säkerhetsrisker och hur skulle vi vilja hantera dem?

I del 1 belyser jag säkerhet ur ett affärsperspektiv, vad är tillräckligt god säkerhet ur organisationens synvinkel? Del 2 blir en godispåse av olika säkerhetstekniker ur ett IT-infrastrukturperspektiv.

”Klientsäkerhet? Jajamensan! Vi har en svindyr brandvägg!”

Ovanstående är en kommentar vi säkerhetsexperter alltför ofta har hört och nu vill jag punktera den känsla av falsk trygghet som ofta finns på företag och organisationer. Nämligen känslan att allt är bra eftersom inget har hänt (vad man vet). Problemet är att vi IT-proffs ofta underblåser den känslan. Hur då? Vi kan raskt konstatera att IT området är stort, brett och djupt, komplicerat och fascinerande. När tekniker försöker förmedla den känslan för icke-tekniker uppstår snabbt språkförbistringar och ämnesglidningar. Säg den ledningsgrupp som förstår begrepp som nätverkssegmentering, PKI, stark autentisering, patch management, SSL VPN och andra häftiga tekniska lösningar och jag kan sätta en vacker slant på att det har skett många möten mellan ledningen och duktiga tekniska kommunikatörer som kan förklara vad teknik XYZ har för bäring på organisationens affärsrisker.

Vad vill ledningen höra?
Smaka på detta: Det här är denna fråga ledningen vill ha svar på: Vilka affärsrisker hanteras genom införandet av systemet, tekniken eller processen?

Problem ur verkligheten/skyttegraven
Vi tar ett exempel: En kund hade identifierat ett problem i informationshanteringen, användarna sparade mängder av affärshemligheter på sina laptops. Detta hade flera säkerhetsimplikationer och risken att en laptop med känslig information skulle tappas bort och informationen hamna på villovägar bedömdes som stor.

Säkerhetsexperternas reaktion
Knäreflexen från oss säkerhetsfolk är att lösa problemet på bästa tekniska sätt, men är det verkligen rätt? Diskussioner fördes kring informationsklassning, DLP (data loss prevention), inlåsning av informationen i säkra digitala valv, starkare autentisering och andra tekniker som, i ärlighetens namn, kostade mer än de smakade för just den organisationen. Även om datat hade ett skyddsvärde fanns det som alltid en budget att hålla sig till, begränsade resurser och för få tekniker (kängor i leran) som kunde drifta den fantastiska tekniska lösningen som skulle förinta dataförlustrisken.

Resultatet
Vad hände? Jo, det blev en lösning som fick anses som ”good enough”: Full hårddiskkryptering med central hantering. Eftersom kunden redan hade rullat ut en version av Windows där licensen för BitLocker ingick (Windows Vista Ultimate i det här fallet, men funktionen ingår även i Windows 7 Enterprise och Ultimate). De privata nycklarna gömdes i TPM chippet användarna fick autentisera sig med en lagom komplex PIN kod när de startade datorn eller väckte den från viloläget. BitLocker är inte en perfekt lösning men det bedömdes som tillräckligt för att hantera risken.

Framtida satsningar
I förlängningen förs det fortfarande diskussioner att bygga en säkrare miljö med smartkortsautentisering av användarna men även här är det affärsverksamheten som måste vara drivande. Därför ses smarta kort inte som en säkerhetsåtgärd utan som ett sätt att förenkla för både användarna och IT-organisationen. Man planerar att knyta ihop inloggningssystemet med passersystemet. Effekten skulle bli att man utnyttjar den befintliga rutinen för kontaktlösa passerkort och lägger till ett smartkortschip på korten för inloggning mot Active DirectorySSL VPN). Användarna skulle i.s.f. uppleva att de får kortare ”lösenord” (PIN koden till smartkortet) och snabbare inloggning mot VPNet. IT-avdelningen skulle spara stora pengar genom att slippa hantera många fall där användarna glömt bort sina lösenord, kortutfärdarna (receptionen i detta fall) skulle märka av ett par extra moment för att registrera smartkorten (certifikatsutfärdningen).

Slutsatsen
Om den satsningen blir av eller inte kommer att avgöras på det krassa ekonomiska budgetbordet. Är detta en åtgärd som hanterar en affärsrisk? Är detta en åtgärd som höjer produktiviteten hos användarna? Vilka problem kan inträffa, särskilt med avseende på tillgänglighet? Och så vidare. Slutsatsen blir som alltid:
Bygg systemen rätt!Bygg rätt system!

Samma tid samma kanal
I del 2 av denna bloggpost kommer jag att fokusera på vad man kan bygga inte vad man borde bygga. Motsägelsen är uppenbar, först säger jag att man skall bygga det affärsverksamheten behöver, i nästa andetag springer jag iväg och vill bygga det tekniker med fuktiga ögon (och tro det eller ej, helt utan ironi) kallar Det Perfekta Systemet. Meningen är att ge läsaren en godispåse att välja ur. Vad behöver vi? Vad vill vi ha? Vad har vi råd med? Prioriteringen lämnas som hemarbete åt den intresserade läsaren eller varför inte i samråd med undertecknad?

Välkommen åter!

Peter Swedin
domänen (Windowsinloggning) upplåsning av krypterade USB minnen och autentisering mot distansarbetsplatsen (