John Wilander på OWASP Sweden Blog har skrivet en mycket bra postning om HTTP Strict Transport Security, en teknik (just nu en IETF Internet Draft) för att eliminera man i mitten-attacker i SSL/TLS. Se även till att läsa diskussionerna i kommentarerna.
Posts Tagged ‘Internet’
Bra blogpost om Strict Transport Security
August 22nd, 2010Ny TCP-sekvensgenerator för uIP
July 17th, 2010Tillsammans med Adam Dunkels har jag börjat titta lite försiktigt på att hitta en bättre generator för TCP-sekvensnummer till den miniskula TCP/IP-stacken uIP.
Adam Dunkels – pappa till uIP, bland annat.
Den nuvarande generatorn ger en monotont ökande sekvens som är lätt att prediktera. En ny generator skall ge en bra slumpmässig som inte är lätt (inte går) att prediktera. MEn samtidigt får storleken på stacken inte växa speciellt mycket och skall gå att implementera på en 8-bitars processor. Vidare får vi inte inför en massa nya krav på målsystemet, exempelvis tillgång till bra fysisk entropi. En icke-trivial kombination av krav.
Jag har tänkt, kladdat och sedan postat på Cryptography-listan och fått en del tips. Men jag (vi) tar med stor glädje emot mer klokskap. Här kommer därför min postning till listan. Läs, kommentera. Tack!
uIP [1] is a very compact TCP/IP stack for small, networked connected, embedded devices. (The code size for uIP including TCP and ICMP on the AVR processor is about 5 kBytes.)
Unfortunately, the TCP sequence number generator in uIP is a bit simplistic – basically a monotonically increasing number. In order to reduce the opportunities for TCP Spoofing (like this nice one [2]) we are trying to implement a new TCP sequence number generator.
What we want to find is an algorithm that generates a good (secure) TCP seq numbers, but use very little resources (on 8-bit computing devices).
We have done some preliminary investigations, have some rough ideas and would really appreciate comments and suggestions from the enlightened minds on this list.
As we see it, the two main problems to solve are:
(1) Find a secure PRNG algorithm that have as low implementation complexity as possible.
(2) Add as little system/application requirements on entropy source and persistent storage as possible.
Looking at TinyRNG [3] for example, it seems that a block cipher in CTR mode (or OFB mode) should be sufficient. The question then is what block cipher to use? The XTEA block cipher [4] is very compact, but would it be a wise choice from a security perspective?
But what to feed the PRNG with? Looking again at TinyRNG, it uses a simplistic version of the entropy accumulator from the Fortuna PRNG [5], but with fewer and smaller pools. The pools are processed using a CBC-MAC built around the same block cipher as used in the PRNG.
The combined storage for the pools as well as CBC-MAC state would probably be acceptable for uIP. The question is if the pool feeding operation as such adds operational requirements on uIP that makes it harder to integrate?
A simpler scheme could be to feed the PRNG (CTR-mode) with entropy used as part of Key and IV, that is not use a pool mechanism at all and leave it to user application to provide entropy words when performing a reseed. The Key (and IV?) would also consists of a counter that is monotonically increased.
The problem with this (we guess) is that in order to ensure that KEY+IV is never reused is to keep at least part of KEY or IV as a counter that is stored in persistent memory and increased once (and stored) every time reseed (or boot) is performed. (How bad from a security perspective would this be? Compared to other TCP sequence generators?)
The current version of uIP places few (basically no) demands on the system/application regarding physical resources (besides mem for code and data) and does not use any persistent storage besides code memory. It seems that any good sequence generator that are driven by physical entropy and tries to avoid sequence repetition need to place additional demands on the system. No?
This is basically as far as we have taken this. More or less a bit of Googling, reading and attempts at thinking. The ambition is not to invent something new and unproven but to adapt existing tech and ideas that seem to work. But get it to work with the size, performance and API constraints of uIP.
Any thoughts, comments, suggestions and pointers would be very greatly appreciated.
Thank you!
Joachim Strömbergson
References
http://www.sics.se/~adam/uip/index.php/Main_Page
—————
[1] A. Dunkels. uIP TCP/IP stack.
[1] R. Lawshae. Picking Electronic Locks Using TCP Sequence Prediction
http://www.defcon.org/images/defcon-17/dc-17-presentation/Ricky_Lawshae/defcon-17-ricky_lawshae-picking_electronic_locks-wp.pdf
[3] A. Francillon, C. Castelluccia. TinyRNG: A Cryptographic Random
Number Generator for Wireless Sensors Network Nodes
http://planete.inrialpes.fr/~ccastel/PAPERS/TinyRNG.pdf
[4] R. M. Needham, D. J. Wheeler. Tea extensions.
http://www.cix.co.uk/~klockstone/xtea.pdf
[5] Wikipedia. Fortuna PRNG.
http://en.wikipedia.org/wiki/Fortuna_%28PRNG%29
Draft med referensbeskrivning för ECC
May 11th, 2010Det finns en intressant Internet Draft (I-D) av (David) McGrew från Cisco och Igoe från USAs National Security Agency.
David McGrew.
Draften Fundamental Elliptic Curve Cryptography Algorithms (draft-mcgrew-fundamental-ecc-02.txt) ger en referensbeskrivning av Elliptic Curve-krypto (ECC).
Varför är nu detta intressant? Jo – som författarna själva skriver:
The adoption of ECC has been slower than had been anticipated, perhaps due to the lack of freely available normative documents and uncertainty over intellectual property rights.(Notera att jag flyttat om ordningen på styckena.)
...
...
This note contains a description of the fundamental algorithms of ECC over fields with characteristic greater than three, based directly on original references. Its intent is to provide the Internet community with a summary of the basic algorithms that predate any specialized or optimized algorithms, which can be used as a normative specification. The original descriptions and notations were followed as closely as possible.
...
...
These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B.
Jag håller med om att det länge behövts en bra beskrivning av ECC. Men att det Just är patenträttigheter på ECC som hållit tillbaka utvecklingen verkar de flesta vara överens om. Som någon på Cryptography-listan konstaterade ger draften inte bara en normativ beskrivning av ECC, den sammanställer även en referens som är mer än 15 år gammal och föregår därmed de patent som idag finns på ECC.
Längd på nycklar och säkerhet
May 10th, 2010Jag har den senaste tiden fÃ¥tt flera frÃ¥gor om längder pÃ¥ kryptonycklar – frÃ¥gor om vad som är säkert, hur lÃ¥ng en assymetrisk nyckel skall vara för att motsvara en symmetrisk nyckel av en viss längd osv.
Det finns flera källor för information om nyckellängder. Den som ofta förekommer är den i idag något gamla boken Applied Cryptography av Bruce Schneier som i kapitel sju har ett längre resonemang om olika nycklar och längder.
Vidare har NIST publicerat rekommendationer om nyckellängder, deras rekommendationer är dock från 2007. Även IETF har publicerat en RFC, RFC 3766 - Determining Strengths For Public Keys Used For Exchanging Symmetric Keys som innehåller ett längre resonemang om nycklars styrka, hur nyckellängder behöver skala med tiden, samt rekommendationer för assymetriska nycklar.
Det många av dessa källor tyvärr har gemensamt är att dom inte uppdateras speciellt ofta (alls). Webb-baserade källor borde därför vara av intresse att titta närmare på.
WIkipedia har förvirrande nog (minst) två sidor i ämnet, dels en sida om nyckellängder och en sida om kryptonycklar, båda med text om nycklar och längder. Borde nog slås samman och städas upp för att det skall bli användbart.
När jag letat runt efter olika referenser hittade jag att belgiska konsultfirman BlueKrypt har en fin sida som sammanställer rekommendationer om nyckellängder.
Den i mitt tycke bästa källan är dock en rapport. ECRYPT Yearly Report on Algorithms and Key Lengths, utgiven av det EU-finansierade ECRYPT II-projektet.
Som namnet antyder är det här en rapport som uppdateras en gång om året. Den senaste versionen kom ut sommaren 2009. Rapporten innehåller ett ordentligt resonemang om hur nycklars styrkor bör värderas (inklusive diskussioner om metoder som NIST, IETF och andra använder). Resonemanget leder så småningom fram till ett antal rekommendationer.
En viktig sak man gör i ECRYPT II-dokumentet är att sätta in styrkan i nycklar i hur kostsamt (rent ekonomiskt) det är att attackera en viss längd:
Jämför dom sedan olika typer av nycklar – symmetriska, assymetriska baserade pÃ¥ RSA, logaritmer eller ellitic curves fÃ¥r kommer dom med följande rekommendationer:
Slutligen sätter dom in längderna i ett tidsperspektiv – hur lÃ¥ng tid kan man anta att en nyckel med en viss längd ger ett skydd:
Vill du skydda något i 10 år från idag bör du alltså välja minst 96 bitars symmetrisk nyckel eller en RSA-nyckel på drygt 2400 bitar.
Allt detta förutsätter dock att algoritmerna som används inte har nÃ¥gra svagheter. Den andra delen av ECRYPTS rapport innehÃ¥ller en genomgÃ¥ng av de vanligaste algoritmerna inom olika kategorier – krypton, hashfunktioner, signaturer etc (DES, 3DES, AES, RSA, MD5, SHA etc). För varje kategori och specifik algoritm presenterar ECRYPT aktuell status vad gäller säkerhet och kommer med rekommendationer om vad man bör och inte bör använda. Mycket bra läsning.
En sista sak: exportreglerna för krypto i Sverige säger maximalt 56 bitar symmetrisk kryptering och maximalt 512 bitars assymetrisk kryptering (antagligen RSA) eller 112 bitar (antagligen elliptic curve).
Ny Internet Draft: Test vectors for the stream cipher RC4
May 4th, 2010Igår kväll släppte Simon Josefsson och jag den första versionen av en ny Internet Draft vi hackat på ett litet tag.
Test vectors for the stream cipher RC4 (draft-josefsson-rc4-test-vectors-00) försöker lösa ett problem vi ser finns när man försöker implementera varianter av strömkryptot RC4.
Eftersom RC4 frÃ¥n början inte är en öppen standard har det inte funnits en tydlig specifikation med testvektorer att använda för att verifiera att implementationen är funktionellt korrekt. Vidare, dÃ¥ RC4 har en del säkerhetsproblem – inte minst problemet med att den läcker nyckelinformation under de första genererade värdena efter initiering finns det ett antal versioner av RC4 där ett visst antal värden skall kastas bort.
Ett exempel på en sådan standard är Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol (RFC 4345). Denna standard beskriver två versioner av RC4, arcfour128 och arcfour256. För dessa versioner skall de första 1536 värdena kastas bort.
Vår draft innehåller testvektorer genererade med två olika typer av nycklar med längder från 40 till 256 bitar. För varje nyckel och nyckellängd specificerar vi 32 Bytes runt ett flertal punkter i nyckelströmmen, exempelvis just 1536. Under arbetet har vi testat ett flertal implementationer av RC4 i exempelvis libgcrypt och andra bibliotek så väl som fristående implementationer, detta för att få så stor konfidens i att vektorerna är korrekta som möjligt.
Vi skulle uppskatta kommentarer och synpunkter pÃ¥ draften sÃ¥ om du läst igenom, ser nÃ¥got fel som strular, kommer pÃ¥ nÃ¥got som borde vara med, tas bort eller ändras – hör av dig till mig eller Simon!
Tack!
Beslut om förstärkt IT-incidentberedskap
April 15th, 2010Enligt ett pressmeddelande från igår 2010-04-14 har Regeringen fattat beslut om förstärkt IT-incidentberedskap:
För att stärka samhällets informationssäkerhet och förmåga att förebygga och hantera IT-incidenter har regeringen idag beslutat om följande uppdrag till Myndigheten för samhällsskydd och beredskap (MSB) samt Försvarets radioanstalt (FRA).
Säker digital informations- och kommunikationsinfrastruktur säkerställer samhällets incidenthanteringsarbete
– I samhället finns det behov av en administrativ och teknisk infrastruktur för informationsdelning och respons där samtliga aktörer av betydelse för informationsinfrastruktur bör finnas representerade. MSB ska därför lämna förslag pÃ¥ hur en säker digital informations- och kommunikationsinfrastruktur för myndigheter, kommuner och landsting kan skapas. Uppdraget handlar inte om att bygga helt ny infrastruktur. Systemet ska närmast bygga pÃ¥ samt nyttja befintlig infrastruktur. MSB ska genomföra uppdraget i samrÃ¥d med andra berörda aktörer bland andra de som ingÃ¥r i SAMFI (Försvarets radioanstalt, Försvarets materielverk, Post- och telestyrelsen, Försvarsmakten och Säkerhetspolisen), Totalförsvarets forskningsinstitut, Skatteverket samt Delegationen för e-förvaltning.
Nationell plan för att hantera IT-incidenter och klargöra ansvar och roller
– Det finns behov av att klargöra ansvar och roller pÃ¥ nationell nivÃ¥ samt att ange processer och rutiner för den nationella hanteringen av IT-incidenter. UtgÃ¥ngspunkten är ansvarsprincipen. MSB ska därför ta fram en nationell plan som klargör hur allvarliga IT-incidenter ska hanteras samt skapa tekniska kompetensnätverk av experter som kan stödja samhället vid allvarliga IT-incidenter för att skapa en ökad förmÃ¥ga till respons. Planen ska ocksÃ¥ ta hänsyn till den viktiga roll som näringslivet och andra organisationer har. MSB ska genomföra uppdraget i samrÃ¥d med andra berörda aktörer bl.a. de som ingÃ¥r i SAMFI (Försvarets radioanstalt, Försvarets materielverk, Post- och telestyrelsen, Försvarsmakten och Säkerhetspolisen), Totalförsvarets forskningsinstitut, Skatteverket samt Delegationen för e-förvaltning.
Obligatorisk incidentrapportering för statliga myndigheter
– Det finns ett behov av incidentrapportering hos statliga myndigheter för att löpande kunna bidra till en aktuell lägesbild av tillstÃ¥ndet vid samhällsviktig verksamhet och kritisk infrastruktur. MSB därför ska utreda hur ett system för obligatorisk IT-incidentrapportering för statliga myndigheter kan utformas. Övriga aktörer i samhället bör erbjudas att pÃ¥ frivillig basis delta i ett sÃ¥dant system.
Analysera och bedöma omvärldsutvecklingen avseende hot, sÃ¥rbarheter och risker inom informationssäkerhetsomrÃ¥det – bidrar till att prioritera skyddsÃ¥tgärder
– I arbetet med att prioritera skyddsÃ¥tgärder ingÃ¥r att analysera och bedöma omvärldsutvecklingen avseende hot, sÃ¥rbarheter och risker inom informationssäkerhetsomrÃ¥det. MSB ska därför kontinuerligt analysera och bedöma omvärldsutvecklingen avseende hot, sÃ¥rbarheter och risker inom informationssäkerhetsomrÃ¥det samt konsekvenser för viktiga funktioner i samhället. MSB:s rapportering ska beskriva hot, sÃ¥rbarheter och risker pÃ¥ informationssäkerhetsomrÃ¥det kopplat till de Ã¥tgärdsförslag som föreslÃ¥s i den nationella handlingsplanen för informationssäkerhet.
IT-säkerhetsanalyser – hjälp för att höja säkerheten hos myndigheter
– För att skapa en tydligare koppling av informationssäkerhet till samhällets krisberedskap och arbetet med samhällsviktig verksamhet och kritisk infrastruktur ska MSB ha möjlighet att föreslÃ¥ myndigheter att anlita Försvarets radioanstalt (FRA) för IT-säkerhetsanalyser. MSB ska ha möjlighet att utifrÃ¥n analyser av förmÃ¥gebedömningar, genomförda risk- och sÃ¥rbarhetsanalyser samt bedömningar av beroendeförhÃ¥llanden föreslÃ¥ enskilda myndigheter att anlita FRA för IT-säkerhetsanalyser. I dag genomför FRA IT-säkerhetsanalyser hos myndigheter som efterfrÃ¥gas stöd för detta.
Tidig förvarning / upptäckt av IT-intrång möjliggör snabba motåtgärder
– I dag saknas det möjlighet att skapa en helhetsbild som omfattar detektering av verkliga och potentiella intrÃ¥ng i informationssystem. Som ett bidrag till att stärka lägesbilden samt för att skapa möjlighet till förvarning ska MSB lämna förslag pÃ¥ hos vilka aktörer ett tekniskt detekterings- och varningssystem för samhällsviktig verksamhet och kritisk infrastruktur kan införas. MSB ska särskilt beakta det uppdrag till FRA som regeringen beslutat om den 14 april 2010.
Utformning av detekterings- och varningssystem mot intrångsangrepp
– I dag saknas det möjlighet att skapa en helhetsbild som omfattar detektering av verkliga och potentiella intrÃ¥ng i informationssystem. Som ett bidrag till att stärka lägesbilden samt för att skapa möjlighet till förvarning ska FRA lämna ett förslag pÃ¥ hur ett tekniskt detekterings- och varningssystem för samhällsviktig verksamhet och kritisk infrastruktur kan utformas och införas. Detta system syftar till att stärka skyddet för samhällsviktig verksamhet och kritisk infrastruktur. FRA ska särskilt beakta det uppdrag till MSB som regeringen beslutat om den 14 april 2010.
Att myndigheterna och andra offentliga aktörer kan kommunicera på ett säkert sätt är en förutsättning för god nationell informationssäkerhet. I det svenska samhället behövs en administrativ och teknisk infrastruktur vid kriser och olyckor för informationsdelning och respons i vid mening, där samtliga aktörer av betydelse för samhällets kritiska informations¬infra¬struktur finns representerade. En sådan stödorganisation och infrastruktur behöver ha en hög informationssäkerhet för att inte slås ut vid allvarliga störningar. Regeringen anger i budgetpropositionen för 2010 (prop.2009/10:1, bet 2009/10:FöU1, rskr. 2009/10:104) att rapportering av IT-incidenter som utgör hot mot eller medför allvarliga konsekvenser för samhällsviktig verksamhet och kritisk infrastruktur behöver förbättras.
Storskaliga IT-incidenter blir snabbt tvärsektoriella frågor som kräver ett samfällt agerande från många olika aktörer. Vid angrepp som drabbar kritisk infrastruktur och samhällsviktig verksamhet saknas det för närvarande möjlig¬het att skapa en samlad lägesbild. En sådan lägesbild handlar dels om att detektera verkliga och potentiella intrång, dels om att studera avvikelser från normalbilden. I dag förfogar nätoperatörerna och andra aktörer var och en över sin del av lägesbilden, men ingen av dem kan i dag se helheten.
Uppdragen ska redovisas senast 1 mars 2011 till Regeringskansliet (Försvarsdepartementet).
MSB fick alltså huvudansvar och rollen som förare.
Informationssäkerhet.se
April 12th, 2010Myndigheten för Samhällsskydd och Beredskap (MSB) har startat en ny webbsida om informationssäkerhet kallad… Informationssäkerhet.se.
Just nu finns det inte så mycket information på webbsidan annat än beskrivning av syftet och vad som avses att komma:
Här ska du snart hitta stora delar av det stödmaterial du behöver för att arbeta med informationssäkerhet på ett systematiskt sätt. Informationsmängden på webbplatsen är i nuläget begränsad men kommer att växa efter hand.På webbplatsen publicerar vi inte bara färdiga produkter. Det är lika viktigt att ta tillvara kunskap och erfarenhet från praktiskt informationssäkerhetsarbete. Du kan följa och delta i arbetet med att ta fram stöd genom att lämna synpunkter på dokument under framställan. Målet är att skapa praktiskt användbara och konkreta resultat med en bred förankring.
Mycket på webbsidan handlar om dokument och processer för att arbeta med Informationssäkerhet. Det finns bland annat en fin vattenfalls-figur på sidan om
Tyvärr verkar det inte gå att surfa säkert till Informationssäkerhet.se. Försöker man ta sig dit med HTTPS får man ingen kontakt.
OpelSSL når 1.0.0
March 30th, 2010OpenSSL, Open Source-biblioteket som implementerar Secure Sockets Layer (SSL v2/v3) och Transport Layer Security (TLS v1) släpptes igår (2010-03-29) i version 1.0.0.
Den nya releasen innehåller ett flertal fixar och nyheter (ChangeLog), men varför man valde att gå till 1.0.0 nu är inte helt klart. OpenSSL som projekt startade i december 1998 och första versionen var 0.9.1c(!). Sedan dess har man under nästan tolv års tid harvat med 0.9.x-inkrement.
Psykologiskt är det dock viktigt att det nu finns en 1.x-version av OpenSSL – för en utomstÃ¥ende kan det vara svÃ¥rt att tro att nÃ¥got med version 0.9.8n är stabilt och lämpligt att använda i seriösa tilämpningar. Tittar man längst upp i ChangeLog ser det ut som att nästa version kommer att heta 1.1.0 sÃ¥ dom verkar gÃ¥ mot mer normala versionsnummer.
För den som vill tanka ner version 1.0.0 av OpenSSL finns den här.
Uppdaterad 2010-03-31:
Hittade en pressrelease från OpenSSL som beskriver 1.0.0-releasen:
The OpenSSL project team is pleased to announce the release of version 1.0.0 of our open source toolkit for SSL/TLS. This new OpenSSL version is a major release and incorporates many new features as well as major fixes compared to 0.9.8n. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES .
The most significant changes are:
o RFC3280 path validation: sufficient to process PKITS tests.
o Integrated support for PVK files and keyblobs.
o Change default private key format to PKCS#8.
o CMS support: able to process all examples in RFC4134
o Streaming ASN1 encode support for PKCS#7 and CMS.
o Multiple signer and signer add support for PKCS#7 and CMS.
o ASN1 printing support.
o Whirlpool hash algorithm added.
o RFC3161 time stamp support.
o New generalised public key API supporting ENGINE based algorithms.
o New generalised public key API utilities.
o New ENGINE supporting GOST algorithms.
o SSL/TLS GOST ciphersuite support.
o PKCS#7 and CMS GOST support.
o RFC4279 PSK ciphersuite support.
o Supported points format extension for ECC ciphersuites.
o ecdsa-with-SHA224/256/384/512 signature types.
o dsa-with-SHA224 and dsa-with-SHA256 signature types.
o Opaque PRF Input TLS extension support.
o Updated time routines to avoid OS limitations.
We consider OpenSSL 1.0.0 to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible.
ACTA har läkt ut
March 24th, 2010ACTA - Anti-Counterfeiting Trade Agreement, det stora, internationella avtalet om immateriella rättigheter som förhandlas fram bakom stängda dörrar har läkt ut. På The Pirate Bay finns just nu en torrent för att ladda hem avtalet.
Michael Geist är en person som är i full färd med att analysera ACTA-avtalet och bloggar om vad han hittar samt nyheter om ACTA.
Michael Geist
Kolla in Michaels blogg, väl värd att läsa.
Statistik över elak kod i olika typer av filer
March 9th, 2010F-Secures log har en postning med statistik över elak kod i olika typer av filformat. Att döma av PDF den klart vanligaste filtypen där elak kod följer med.
Det hade naturligtvis varit intressant att se hur vanliga resp format är på över huvud taget. Är det ex så att PDF är vanligaste filtypen där elak kod följer med för att den är lättast att dölja kod, eller för att det helt enkelt är den överlägset vanligaste filtypen av de jämförda typerna. Oavsett hur det ligger till bör man nog inse att PDFer (och andra filer) som trillar ner från nätet kan innehålla elakheter.
