Etikettarkiv: IETF

Bra RFC om identifiering

Kommunicerande system använder och utbyter ständigt olika typer av identifieringsinformation. Exempel på identifieringsinformation är värdnamn, IP-adresser, e-postadresser och resurspekare (Eng: Uniform Resource Identifier – URI).

Men om kommunicerande parter tolkar identifieringsinformationen på olika sätt och hanterar informationen på olika sätt kan problem uppstå. Typiskt kan en legitim användare av en resurs nekas tillgång till resursen. Eller omvänt att en användare (som inte behöver vara en människa) får tillgång till resurser denne inte skall ha tillgång till.

IETF har publicerat en informations-RFC som på ett mycket bra sätt går igenom vilka problem som kan uppkomma vid användning av olika typer av identifieringsinformation. Om du arbetar med att bygga system som på något sätt använder identifieringsinformation är RFC 6943 – Issues in Identifier Comparison for Security Purposes väl värd att läsa igenom. Det är lätt att göra enkla misstag vilka ofta får säkerhetsmässiga konsekvenser. Eller som dokumentet så snyggt sammanfattar det hela:

Screen Shot 2013-06-19 at 09.47.04

Ny draft för att få in Salsa20 i TLS och DTLS

Tillsammans med Simon Josefsson och Nikos Mavrogiannopoulos är Secworks involverade i arbetet att skriva en Internet Draft avsedd att få in strömkryptot Salsa20 i TLS och DTLS.

Skälet till arbetet med draften draft-josefsson-salsa20-tls-01 är att vi ser att det behövs ett bra, säkert strömkrypto i TLS och DTLS. I dag finns bara RC4 som strömkrypto, men RC4 är rejält trasigt. Det finns ett antal blockkrypton, inte minst AES, men de senaste årens säkerhetsproblem har gjort att fler använder RC4.

Att få in ett nytt strömkrypto kräver att det finns en RFC som beskriver hur strömkryptot ska användas i TLS och DTLS och draften är arbetsdokumentet till vad som förhoppningsvis blir denna RFC.

Salsa20 är ett strömkrypto som har kort initieringsfas och därmed ger bra prestanda även för korta meddelanden. Salsa20 går att få att ge bra prestanda på ett flertal olika processorarkitekturer. ARX-strukturen gör att Salsa20 inte öppnar upp för informationsläckage via sidokanaler. Slutligen är Salsa20 relativt väl analyserad då den är en av algoritmerna i eSTREAM-portföljen. Vi tror därför att Salsa20 skulle kunna bli en bra ersättare till RC4 i TLS och DTLS.

Om du har några kommentarer och synpunkter på draften skulle vi som författare uppskatta det mycket. Kontakta oss gärna. Själva arbetet med draften sker på Gitorious.

Presentationer från NISTS sista SHA-3-konferens

I slutet av mars anordnade NIST den sista SHA-3-konferensen. Målet med konferensen var att få in så mycket information som möjligt om finalisterna inför NISTs beslut om vilken algoritm som kommer att blir den nya hashfunktionen SHA-3. NIST har en sida för konferensen och där finns nu alla presentationer och artiklar som presenterades.

Det finns ett flertal intressanta presentationer om implementationer, både i hårdvara och i program. För högpresterande hårdvaruimplementationer i FPGA och ASIC ser finalisten Keccak ut att vara överlägsen, både i ren råprestanda och prestanda viktad mot kostnad. På senaste generationer av CPU:er ser dock BLAKE att vara överlägsen rent prestandamässigt.

För små, inbyggda system ser Gröstl och Blake att ge minimala implementationer med där Keccak återigen ger bäst prestanda viktad mot kostnad. Det finns även intressanta resultat vad gäller sidottacker på implementationer och säkerhetsanalyser av algoritmerna.

På konferensen ställde även NIST frågan till deltagarna om vilka kandidater de föredrar genom att humma. Skaparen av BLAKE, JP Aumasson rapporterde resultatet:

Top: Keccak, then BLAKE. Deafening silence: Skein. Ouch.

När skaparna av finalisterna fick frågan vilken algoritm förutom sin egen de föredrog blev resultatet:

  • Skein -> BLAKE
  • Groestl -> JH
  • JH -> Keccak
  • BLAKE -> Skein
  • Keccak -> Groestl

Om man jämför med humm-frågan ser det ut att vara rätt mycket taktik i de valen.

IETF 83 några dagar efter SHA-3-konferensen höll NIST en mycket intressant presentation om SHA-3 (länken pekar på PPT-fil). För att få en känsla av hur NIST resonerar är den här presentationen väl värd att bläddra igenom. I presentationen pekar man ut att SHA-3 inte kommer att ersätta SHA-2, inte minst då SHA-3 knappast kommer att ge mycket bättre prestanda. NIST ser att SHA-2 är effektiv, inte minst i inbyggda system. Däremot kommer SHA-3 att kunna ge mycket högre prestanda för hashbaserade meddelandekoder (MAC). NIST påpekar även i sin presentation att det analysarbete av kryptografiska hashfunktioner som bedrivits sedan 2005 gör att man i dag är mindre orolig för säkerheten hos SHA-256 och andra SHA-2-algoritmer. NIST ber i sin presentation IETF om synpunkter på hur hashfunktioner bör anpassas för olika protokoll och miljöer, detta för att ta med dessa synpunkter i sitt val av vinnande algoritm.

För den som vill bidra till SHA-3-processen vill NIST få in detta innan den första juni. Sedan är det dags för NIST-juryn att överlägga och berätta vem som är vinnare. (Inte säker på att SHA-3-överläggningen skulle göra sig lika bra i TV som Project Runway.). Enligt NIST kommer vinnaren att utses i slutet av året.

Har du information du anser att NIST bör ta med i sin bedömning är det dags att agera. Sedan blir det spännande att sätta tänderna i den nya, fräscha SHA-3. Nästan som en julklapp.

Vilka algoritmer används i Internetstandarder

Internet Crypto en sida skapad av säkerhetsexperten David McGrew samlar information om användning av olika typer av kryptofunktioner på Internet.

David A. McGrew
David A. McGrew

Med Internet avses i det här fallet huvudsakligen de standarder (Request For Comments – RFC) och förslag till standarder (Internet Draft – I-D) som publiceras av Internet Engineering Task Force – IETF.

Jag tycker att Internet Crypto är en bra sida eftersom den på ett bra sätt samlar och kategoriserar upp den stora mängden standarder och dokument som finns och gör det lätt att hitta. Om du exempelvis vill få reda på vilka standarder det finns för att autenticera meddelanden (Message Authentication Code – MAC) går det lätt att hitta under sin kategori. Det som dock inte finns är rekommendationer om vilka koder som är bra eller dåligt att använda.

Internet Crypto

En sak som finns är intressant kryptostatistik. Statistiken är frekvensen för hur ofta olika typer av kryptostandarder refereras i RFC:er och drafts. Detta ger i alla fall en hum om hur populära vissa algoritmer är. Tio i topp-listan ser ut som följer:

  1. Hashfunktionen MD5
  2. Hashfunktionen SHA-1
  3. Meddelandeautenticeringskoden HMAC
  4. Nyckelutbytesalgoritmen Diffie-Hellman (DH)
  5. Hashfunktionen SHA-2
  6. Blockkruptot AES
  7. Blockkryptot 3DES
  8. Asymmetriska kryptot ECC
  9. Signaturalgotritmen DSA
  10. Asymmetriska kryptot RSA

Att listan domineras av hashfunktioner samt följs av några krypton och metoder för att utbyta nycklar är inte så förvånande – detta är arbetshästarna som skapar säkerheten på Internet. Vi ser även hur AES som blockkrypto verkligen har blivit den stora de facto-standarden bland symmetriska krypton.

Däremot blir jag en aning beklämd när man klickar på listans förstaplats och tittar närmare på MD5. Hashfunktionen MD5 är en algoritm som sedan flera år tillbaka anses vara helt trasig, en algoritm kryptologer och experter rekommenderar att inte använda. MD5 är en gammal algoritm med stor spridning. Att den därför finns i många standarder (RFC:er) är inte speciellt konstigt.

Vad som gör mig beklämd är att det är så många nya, aktiva drafts, alltså förslag till standarder som refererar till MD5. Några av dessa är så kallade informations-drafts. Detta innebär att dom dokumenterar någon form av funktion på Internet, exempelvis ett specifikt applikationsprotoll någon utvecklat. Vidare finns det drafts där MD5 tas upp som varnande exempel. Men tyvärr är det fortfarande ett antal standard-drafts där MD5 pekas ut som komponent att använda.

Vill vi komma bort från en algoritm vi vet inte är säker måste sluta bygga in nya beroenden av algoritmen i framtida standarder. Att 2011 designa något som använder MD5 är fel och det borde ringa varningsklockor. Massor med klockor. Högt och ljudligt. Om du ser någon som ritar, skissar, skriver in MD5 i en ny konstruktion – hjälp denne att komma på bättre tankar. Att byta ut en algoritm är mycket billigare när konstruktionen bara är på designstadiet, inte ute i fält i miljontals burkar i skogen. Att tänka efter före är inte lätt, men i fallet MD5 är det inte så svårt.

Samtidigt sprang jag på en informations-RFC, RFC 5218 – What Makes for a Successful Protocol? som försöker förklara och beskriva varför vissa standarder blir framgångsrika (som MD5 och IPv4). Utan att avslöja för mycket kan jag säga att bästa tekniken inte alltid vinner.

RFC 6229 – Test Vectors for the Stream Cipher RC4

Nu finns RFC 6229 – Test Vectors for the Stream Cipher RC4 publicerad hos Internet Engineering Task Force (IETF).

Detta dokument, skrivet av mig och Simon Josefsson är avsett att underlätta implementationer av strömkryptot RC4 genom att tillhandahålla testvektorer, något som tyvärr saknats. Inte minst viktigt är detta för varianter av RC4 där ett antal av de första nyckelströmsvärden genererade av RC4 förkastas, detta för att förbättra säkerheten. Exempel på denna typ av RC4-varianter är arcfour128 och arcfour256 specificerade i RFC 4345. De testvektorer som finns i vår RFC täcker bland annat in just dessa varianter.

RC4 är ett på många sätt trasigt och svagt krypto och ska inte användas. Tyvärr är ofta verkligheten inte så enkel att det går att helt undvika RC4, detta då algoritmen är väldigt spridd och används i SSL/TLS, WLAN och en oherrans massa applikationer och applikationsspecifika protokoll. Vi ser därför att RFC 6229 bör underlätta vid implementationer och bidra till att bättre varianter som arcfour128 och arcfour256 används där byte till helt andra agoritmer inte fungerar.

Att implementera krypton är intressant och skiljer sig från många andra algoritmer på så sätt att det inte finns något som kan kallas funktionellt nästan korrekt. Antingen är implementationen korrekt eller så är resultatet helfel, bokstavligt talat inte en siffra rätt. Att debugga kryptoimplementationer är därför inte lätt. Tillgång till facit – i form av testvektorer (kallas också Known Answer Test – KAT) och gärna även interntillstånd underlättar betydligt.

Ny version av draft med testvektorer för RC4

Jag och Simon Josefsson har arbetat ett tag med ett utkast till RFC-dokument för IETF med testvektorer för strömkryptot RC4. Efter att ha legat på is ett tag postade vi precis en ny version av utkastet. draft-josefsson-rc4-test-vectors-02 finns nu hos IETF.

Detta är förhoppningsvis den sista versionen av utkastet innan det blir en officiell RFC. Jag och Simon skulle därför uppskatta alla kommentarer och synpunkter på utkastet.

Uppdatering 2011-07-01: Draften har nu omvandlats till RFC 6229.

RFC 6070 – Testvektorer för PBKDF2

Strax efter nyår dök det upp en ny RFC från IETF, RFC 6070 – PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors.

Som namnet anger innehåller dokumentet testvektorer för nyckelgenereringsfunktionen PBKDF2. Denna nyckelgenereringsfunktion specificerads i RFC 2898 och har används i exempelvis RFC 5802. Tyvärr innehåller dessa dokument inga testvektorer eller bra exempel.

För den som ska implementera det dokumenten specificerar blir det därför svårare att veta att implementationen är korrekt. Tyvärr är det inte helt ovanligt att detta saknas i specifikationer. Och för kryptofunktioner, som antingen fungerar eller är fullständigt felaktiga är vektorer och exempel väsentligen tvunget att ha för att lyckas.

Den som tagit fram testvektorerna för PBKDF2 och såg behovet i sitt arbete med att implementera funktionen är Simon Josefsson. Simon berättar mer om RFC 6070 och hur den kom till på sin blog. Väl värd att läsa.