Säkerhetskonferensen SEC-T anordnas i år för tredje gången och går i år den 9 och 10 September.
Arrangörerna har postat agendan för konferensen. Tittar jag på agendan finns det ett par klart spännande presentationer, bland annat en presentation om svagheter i diskkrypteringsprodukter och en presentation om (o)säkerheten hos skrivare.
För den som vill gå på årets SEC-T är det hög tid att anmäla sig.
Tillsammans 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
Jag 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).
Batteriföretaget Energizer släppte för ett tag sedan en USB-kopplad batteriladdare kallad Energizer Duo.
Förutom att ladda via USB kunde produkten köra en liten applikationen på datorn som visade laddstatus fäör batterierna.
Men det var nu inte det enda som kördes när laddaren kopplades in. Enligt Symantec kom batteriladdaren med en elak liten trojan. Symantec har en längre beskrivning av Energizertrojanen som bla beskriver vad den kunde göra:
• Download a file
• Execute a file
• Send a directory listing to the remote attacker
• Send files to the remote attacker
• Modify the following registry entry:
Energizer har dragit tillbaka produkten. Det jag undrar över är hur trojanen hittade in i koden till laddaren från första början. Hade det varit ett USB-minne hade det varit en sak, men nu är det inte det och då brukar mängden minne som finns vara högst begränsat. Märkligt.
F-Secures Mikko Hypponen rapporterar på sin blog om ett intressant sätt att skydda användare av applikationer mot att råka köra elak kod.
Den stora mobilkonferensen GSMA World Congress 2010 börjar nästa vecka och tydligen har företaget Whatamap utvecklat den officiella konferensapplikationen. Miko fick ett meddelande till sin mobil om detta från ett för honom okänt nummer:
Ok, någon vill att han skall köra en applikation. Hur vet man då att det verkligen är den officiella appen och kod man kan våga ladda ner och köra? Jo för att dom säger att det är ok:
Notera texten You can trust this application: it’s the official MWC 2010 mobile guide. Jamendåså, då måste det vara ok. När Mikko försökte köra koden fick han naturligvis följande varning:
Allvarligt talat. Även om det ibland kan vara si och så med hur signering sker, men det är väl ändå bättre än den här typen av trams.
Skall mobilsystemen bli en plattform för säkra transaktioner, ersätta plånböcker och e-handel är det dags att bli seriös vad gäller säkerhet. Och då böja städa i sitt eget bo.
Mobilemag har en artikel om ett test av krypton för att skydda röstkommunikation från mobiler.
Den undersökning artikeln beskriver har utförts av en bloggare och IT-expert som tydligen kallas Notrax. På Notrax blog InfoSecurityGuard finns de egentliga undersökningarna.
Att det finns behov av bra kryptolösningar som erbjuder konfidentialitet från mobiler är helt klart. Dels är de befintliga mekanismerna i såväl GSM som 3G (UMTS) starkt ifrågasatta. Dessutom skyddar dessa mekanismer bara radiolänken. Det finns ett flertal produkter på marknaden som alla (naturligtvis) säger sig erbjuda ett bra skydd. Men hur bra är dom egentligen?
Att döma av Notrax test av 15 olika program- och hårdvarubaserade produkter är dom inte speciellt bra. Han lyckades knäcka 12 av 15 produkter:
Svenska Sectras produkt Tiger XS är tyvärr inte med i undersökningen.
Går man sedan in på Notrax sidor finns det detaljerande beskrivningar av hur han ex knäckte CellCrypt och undersökte PhoneCrypt. Notrax har även gjort videoinspelningar av sina undersökningar och lagt upp på Youtube, här den om CellCrypt:
Sammantaget väldigt intressant och spännande information. Men nu visar det sig (ser det ut som) att Notrax arbetar för företaget SecurStar GmbH som levererar PhoneCrypt, en av de säkerhetsprodukter Notrax inte lyckas knäcka och ger bra betyg! Jösses.
Vem skall man lita på? Antagligen inte de produkter Notrax lyckades knäcka (fast det vore bra om någon mer gjorde om testerna och kom fram till samma sak). Klart är iaf att produkterna behövs – och att dom testas.
Det verkar aldrig ta slut på uppmärksamheten kring Karsten Nohls attack på A5/1 (se tidigare bloggpostning ett och bloggpostning två). I dag har Sveriges Radio och Ekot plockat upp tråden och jösses vilket reportage det blev.
Egentligen är Per Eurenius reportage (webbradio) från 26C3 i Berlin inte så illa, utan det är snarare påannonseringen och SRs nyhetstext som är tokfel:
Hemlig gsm-kod hackad av forskare
En tysk forskare har lyckats avslöja den kod som ska skydda mobiltrafiken i världens största telefonsystem, gsm.
Nej, SR, det är ingen kod som avslöjats, och det är inte hemligt.
Även Cryptome har uppdaterat sitt material In support of Karsten Nohl’s cracking of GSM A5 och den här sidan hos Cryptome är nog den mest kompletta samlingen av information om A5-krypton, säkerhet (eller avsaknad därav) i GSM, GPRS och UMTS.
För den som vill ha Karstens regnbågstabeller finns det nu torrentfiler.
Det har varit en del uppmärksamhet om Karsten Nohls A5/1-projekt. IEEE Spectrum hade en bra artikel som sedan bla ledde till en artikel i Elektroniktidningen här i Sverige.
Karsten Nohl från en tidigare attack på RFID.
Vad det hela handlar om är att Karsten Nohl (bland annat) har bestämt sig för att generera regnbågstabeller för GSM-kryptot A5/1.
Då A5/1 använder en 64-bit nyckel skulle en ren tabell ta upp 128 Petabyte och att generera tabellen med en CPU skulle ta hundatusentals år. Karsten & Co löser dessa båda problem genom att koda/komprimera samt använda GPU:er programmerade med CUDA för att parallellisera beräkningarna.
Det finns en presentation av Karsten Nohl från HAR 2009 om projektet som mer i detalj beskriver tabellkomprimeringen samt hur GPU-accelerationen går till.
Syftet bakom projektet så som det anges i presentationen är att det sedan 1994 publicerats ett antal attacker på A5/1-algoritmen, men trots detta finns det ingen publik exploit eller publikt presenterad praktiskt genomförd attack. Det Karsten vill åstadkomma är därför att ta fram en sådan praktisk attack för att visa att A5/1 verkligen är osäkert, inte bara i teorin (eller om man heter NSA.).
Om du vill följa utvecklingen i projektet finns det en Trac-sida för A5/1-projektet som innehåller statusuppdateringar, kod etc.
Det Karsten hoppas skall ske är att GSM går över till A5/3 (baserat på kryptot Kasumi), vilket används i 3G. Frågan är dock om det kommer att ske. Med flera miljarder med användare kommer det att finnas en enorm mängd mobiler som fortsätter köra A5/1 i många år framöver.
En annan viktig sak att komma ihåg är att oavsett om det är A5/1 eller A5/3 som används är det bara mellan din mobil och basstationen ditt samtal är skyddat. Vill du lita på att ditt samtal inte avlyssnas från dig till den du kommunicerar med bör du betrakta den kanal operatören tillhandahålla och vidta de åtgärder du tycker behövs.
För ett tag sedan började en av de elektroniska nycklarna till vår bil (SAAB 9-3) att krångla. Ibland fungerade den, ibland inte.
Som ägare kan man själv öppna nyckeln och byta batteri, detta hjälpte dock inte så det var inte ett kasst batteri, utan kass elektronik. Samtidigt som man byter batteri kan man titta på vad som borde vara ett KeeLoq-chip.
En trasig elektronisk nyckel ersätts med en ny som behöver paras ihop med bilen med hjälp av en programmeringsenhet de har på verkstaden. Så långt allt väl, men nu kommer det som gjorde mig förvånad: När detta sker måste alla andra elektroniska nyckar vara med, annars kommer de att sluta fungera.
Jag inbillade mig att bilens chip innehöll en accesslista. När den nya nyckeln skall paras ihop med bilen läggs nycklens ID in i listan och den gamla nycklens ID plockas bort. Men tydligen är det inte så det fungerar.
En servicetekniker hävdade att detta förfarande var för att det skulle vara säkrare, vilket jag har svårt att se varför. Han tänkte sig tydligen situationen när en nyckel har tappats bort – men det är ett helt annat användningsfall – här finns den gamla nyckeln kvar så vilken nyckel som skall plockas bort från en accesslista kan inte vara bekymret.
Kan du som läser detta komma på en bra anledning till att behöva para ihop alla nycklar igen med bilen när en nyckel skall ersättas?
Det enda jag kan komma på är att det finns en gemensam gruppnyckel och därmed ingen accesslista. Om jag fattat Keeloq rätt skall dock alla enheter ha ett unikt ID och därmed möjlighet för accessliste-baserad säkerhet.
Dessutom är det så att det finns en fysisk nyckel i den elektroniska som gör att man iaf kan öppna förardörren på gammalt mekaniskt sätt. Och dessa nycklar är inte unika, utan det är samma nyckel i alla de som hör till en bil.
Förra året släppte Krisberedskapsmyndigheten (KBM, numera en del av MSB) en ypperlig rapport om säkerhet för industriella kontrollsystem, även kallade SCADA-system. Rapporten är indelad i tre stora delar.
Den första delen innehåller en definition av vad SCADA system är och vad som skiljer denna typ av system från exempelvis ett administrativt IT-system. Andra saker som tas upp är var SCADA-system finns, hur de används och behovet av skydd.
Den andra delen innehåller en detaljerad beskrivning av rekommendationer och riktlinjer. Efter att ha presenterat PDCA-modellen kommer en genomgång av 15 olika aktiviteter och en av rapporten styrka tycker jag är att varje aktivitet innehåller ett bra, enkelt förklarande exempel på de risker och problem varje aktivitet behandlar. Mitt i allt det komplexa och teoretiska finns alltid ett exempel som visar att det inte behöver vara så krångligt.
PDCA-modellen.
Den tredje delen är en extensiv referenslista över relevanta standarder. Men denna del är inte bara ett appendix, utan varje referens åtföljs av kommentarer som förklarar vad respektive standard och dess delar behandlar och är till för.
Rapporten, framtagen av Åke J. Holmgren (KBM-SEMA), Erik Johansson (KTH) and Robert Malmgren kan med fördel läsas av såväl beslutsfattare som tekniska chefer satta att ansvara för att skydda SCADA-system och tekniker som implementerar skyddet.
Att en svensk myndighet tar fram en sådan här bra rapport gör mig riktigt glad. Heja KBM!
You are currently browsing the archives for the Inbyggda system category.
© 2010 Kryptoblog · Proudly powered by WordPress & Green Park 2 by Cordobo.
Valid XHTML 1.0 Transitional | Valid CSS 3
