Warning: Missing argument 2 for wpdb::prepare(), called in /home/stromber/public_html/kryptoblog/wp-content/plugins/wp-super-edit/wp-super-edit.core.class.php on line 109 and defined in /home/stromber/public_html/kryptoblog/wp-includes/wp-db.php on line 1291
December » 2007 » Kryptoblog

Archive for December, 2007

Enigma och Fialka

December 30th, 2007

De senaste dagarna har jag suttit och julmyst med rotoruppsättningarna till Enigma-maskinen.

Fin bild över Enigma-rotorer

Surfar man runt på nätet inser man snabbt två saker: (1) Det har funnits många olika rotorer och Enigma-varianter. (2) Namngivning av olika rotorer och när de började användas är inte precis entydig. Jag har försökt sammanställa en datastruktur med alla rotorer inkl placering av notch och turnover namn och datum utifrån bland annat de här sidorna:

En sak jag dock inte hade en aning om var att det fanns en rysk/sovjetisk släkting till Enigma kallad Fialka.

Fialka

Enligt den här sidan kom första modellen av Fialka på 1930-talet och användes sedan i olika modeller i alla fall under stora delar av kalla kriget. Den vanligaste modellen verkar vara M-125-MN. Den stora skillnaden gentenmot Enigma är att Fialka hade 10 rotorer och med 30 tecken/rotor istället för de tre till fyra rotorer och 26 tecken för Enigma. Wikipedia har en sida om Fialka, men den tar bara upp M-125-modellen.

Jag hittar ingen analys av säkerheten i Fialka och att någon verkligen knäckt Fialka (och publicerat det). Den större mängden rotorer och tecken/rotor borde göra Fialka starkare än Enigma. Men utan en detaljerad analys går det bara att spekulera.

Och eftersom alla andra sidor påpekar det: Fialka betyder violett. Dock verkar det inte finnas några kopplingar till Japanska kryptomaskinen Purple.

Kul att lära sig lite mer om ett krypto till. Julkul!

Gula lappar och sätt att avslöja säkerhetsproblem

December 29th, 2007

(Det här brukar vara ett hett debattämne så jag sätter väl på mig jul-asbest-kallingarna…)

Bruce Schneier har en postning om sin blogg om hur polisen i Conyers, USA agerar för att minska mängden inbrott i parkerade bilar.

Vad polisen gör i Conyers är att gå runt på parkeringsplatser och titta vad som finns i bilarna.

Polisen letar efter gods att stjäla.

I de bilar polisen ser att det finns värdesaker att sno sätter polisen en varningslapp på bilen. En stor, gul lapp.

Här finns det saker att stjäla!

Men jösses?!

Inom IT-säkerhet pratar man om olika sätt att berätta om/avslöja säkerhetsproblem. Termer som full disclosure, reasonable disclosure används för att beskriva hur någon som upptäcker ett säkerhetsproblem agerar. Det har länge pågått en debatt om för- och nackdelarna med de olika sätten att agera.

Det är sannolikt så att hade vi inte haft folk som öppet rapporterat om svagheter i IT-system hade mängden säkerhetsproblem som fixats varit mycket mindre. Vi har efter åratal av incidenter fått upp ett arbetssätt hos de flesta företag att leta efter svagheter i sina produkter, men även fått arbetssätt att reagera på och hantera svagheter som rapporteras av användare och aktörer.

Samtidigt verkar det finnas en klar koppling mellan en publicerad svaghet och nya svagheter som elak kod använder för att ta över ett system. Att publicera en svaghet får alltså konsekvenser något den som publicerar svagheten måste vara medveten om.

Jag säger inte att man inte skall publicera. Vad jag säger är att den som levererar produkten/tjänsten svagheten är kopplad till måste få en chans att reagera. Men om denna inte reagerar går det inte heller att vänta i all evighet. Så publiceringen måste ske. Den stora frågan är vad som tas med i publiceringen. Vad är det som avslöjas om svagheten?

Detta är en svår balans. Den som publicerar vill kunna visa upp så mycket att andra skall kunna verifiera att det finns en svaghet. Samtidigt kan detta innebära att de som vill utnyttja svagheten för onda syften snabbt kan ta till sig svagheten och omsätta den i verkliga attacker.

Tittar man på publicerade svagheter varierar innehållet från allmänna beskrivningar, ex ett fel av typ XYZ har upptäckts i delen ABC av produkten GHI, till färdiga program och script för att utnyttja svagheten. Även om jag kan tycka att det är kul att testa en del exempelkod anser jag att det på det stora hela är oansvarigt.

Ett Svenskt exempel på vad jag anser vara oansvarigt avslöjande är hur Dan Egerstad på Deranged Security i höstas postade inloggningsuppgifter för eposten till olika ambassader runt om i världen på sin webbplats. Att undersöka Tor är helt rätt, att när man upptäcker säkerhetsproblem kontakta de drabbade är helt rätt. Men att hänga ut de drabbade på det sätt Dan gjorde är fel. Mycket fel.

Jag har svårt att se att polisen i Conyers agerar mycket annorlunda. Att de går runt och upptäcker att folk är slarviga med att plocka undan värdesaker är helt rätt. Men sättet man agerar för att få bilägarnas (användarnas) uppmärksamhet är fel. Man hade kunnat agera mycket annorlunda. Ex skriva upp bilnumren och sedan skicka brev (eller tom böter) till bilägarna.

Och detta kanske är poängen: Även om det är en myndighet, tom den polisiära makten som avslöjar ett säkerhetsproblem eller en svaghet går det inte att agera hur som helst. När SVT avslöjar att ICA-handlare märker om köttfärs är detta inget som drabbar utan gagnar konsumenterna. Men när polisen hjälper biltjuvarna att hitta till godsakerna är det fel sätt att agera.

Säkerhetsproblem är dumt, men det gör inte att vi kan agera korkat när vi upptäcker dom.

Uppdatering 2008-01-03:
Björn Persson pekade på att det skett en uppdatering i historien om polisen och deras gula lappar. Justin Troutman, en av användarna på Bruce Schneiers blog kontaktade polisen i Conyers och fick deras förklaring:


I contacted Conyers Police Department, basically iterating the same thought that this lets thieves know which vehicles they should be paying attention to.

Their response to me was:

“Thank you for contacting the Conyers Police Department. We appreciate that you took the time to write us with your comments about our flyer initiative.

Unfortunately, the media did not impart the whole story in regard to the flyers. Flyers were not just placed on vehicles that contained visible items. Flyers were also placed on vehicles that contained no visible items with a note saying “Nothing Observed (Good Job!)”. All vehicles were targeted. This initiative was not aimed only at vehicles that had items actually visible. Therefore, the flyers would not have been of any use to a thief for targeting vehicles since vehicles without items also received flyers. In addition, it was also not reported that all of the areas had extra patrols and officers on foot who were distributing the flyers.

We are sorry that the media did not provide this information despite the fact we asked them to. We hope that makes you see that our initiative was better planned than you believed.”

Hopefully, thieves won’t be able to easily differentiate between a flyer that indicates loot versus a flyer that indicates no loot; if the former looks noticeably different, they’ll ignore the latter.

Dvs man lappade alla bilar – Men notera att det fanns en skillnad i hur lapparna såg ut, det är inte uppenbart om skillnaden gör det enkelt att identifiera (för tjyvar) intressanta bilar eller ej.

IMEGO och andningsbaserad biometri

December 22nd, 2007

(Mycket biometri från Göteborg just nu.)

I går kväll diskuterades alkolås på bilar och möjligheten att sälja utandningsluft på tub som ett sätt att gå runt systemet. Det visade sig att statligt ägda företaget IMEGO har varit engagerade att utveckla sensorer som kan detektera att det är en levande människa som andas.

Det finns en artikel publicerad som beskriver vad man gör. Tydligen tittar man på både luftens temperatur och hur koldioxidhalten varierar under ett andningsprov, detta för att mängden koldioxid varierar beroende på vilken del av lungorna luften kommer ifrån.

Googlar man lite hittar man en del länkar till andningsbaserad biometri. De flesta av dessa ser ut att ta fasta på att det följer med en del celler varje gång man andas ut, och att det då skulle gå att titta på DNA:t i cellerna för att identifiera personer. Jag hittar dock mest patent men inga konkreta produkter.

Och av någon anledning dök en sida om Binaural Phasing från Harmonic Resolution upp, fast då började knäppklockorna ringa…

Ny biometriprocessor från FPC

December 22nd, 2007

Biometriföretaget Fingerprint Cards (FPC) från Göteborg har släppt en en ny biometriprocessor till sina sensorer. (Ja, för en månad sedan – jag är inte så snabb.)

FPC2020

FPC2020 är anpassad för att fungera med FPCs areasensor FPC1011C.

FPCs areasensor

FPC2020 integrerar hårdvara för bildbehandling, acceleration av biometriska algoritmer och en kontrollprocessor.

Detta gör att man inte som tidigare behöver någon extern processor, ex en ARM eller en AVR. Utan det man behöver för att bygga in en biometrifunktion är en sensor, ett seriellt FLASH-minne, en kristall och FPC2020. (FPC skriver inget om innehållet i FLASH-minnet är skyddat och hur.)

Det finns ett datablad med detaljerad information om FPC2020 inklusive API:t för att använda kretsen. I det kan man bland annat hitta följande information.

Antalet användare som kan hanteras beror på storleken på externa FLASH-minnet. Med 2 Mbit klarar FPC2020 att hantera 223 olika templates. Största FLASH-minnet FPC2020 verkar stödja är 8 Mbit vilket ger kapacitet för 991 templates, men FPC skriver att man bör hålla nere antalet templates till mindre än 500.

Verifiering mot en enskild template tar ca 0.2 sekunder. Registrering (Enrolment) tar däremot hela sju sekunder. Normalt sett gör varje användare en eller ett fåtal registreringar och massor med verifieringar så verifieringstiden är det som är viktigt att få snabbt. Men sju sekunder är ändå tillräckligt lång tid för att man skall börja fundera på om det gick bra eller ej.

Vad gäller säkerheten skriver FPC att False-Rejection-Rate (FRR, dvs man godkänner inte ett tidigare registrerat fingeravtryck) går att justera och beror på indata. Även False-Acceptance-Rate (FAR, dvs man accepterar ett icke registrerat fingeravtryck) är ställbar från 1/1000 till 1/100.000. Vid 1/100.000 får man en FRR på mindre än 7 %.

Säkerhetsmässigt är ett lågt FAR-värde mycket viktigt. Däremot är ett lågt FRR-värde viktigt för att systemet inte skall kännas bökigt att använda.

En liten märklig detalj. Jag hittar ingen information på FPCs webbplats vad som hänt deras sweepsensorer FPC1030 och FPC1031.

Krokodilen?

Bilden ovan hittade jag på den här webbplatsen. På den sidan står det att FPCs sensorer utvecklats av ett företag i Holland kallat Xensor. En annan märklig detalj är att bilden ovan heter Krokodilen?!

Personligen föredrar jag sweepsensorer före areasensorer. Jag tyckte att FPCs sweepsensorer i förhållande till areasensorn var mycket trevligare att arbeta med, tog mindre plats och dessutom inte kan ha några problem med kvarlämnade (latenta) fingeravtryck på sensorn.

FPC2020 kommer kapslad i en liten och trevlig 64-bens QFN-kapsel. FPC2020 klarar matning från 2.5V till 3.3V och kommunicerar mot omvärlden via RS-232 (vilket FPC kallar UART) eller SPI-interface.

Nya säkerhetsrelaterade RFC:er

December 16th, 2007

IETF har publicerat några nya RFC:er som berör krypto och IT-säkerhet. Notera att dessa är klassade som PROPOSED STANDARD.

RFC 5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication


The IETF has two sets of standards for public key certificates, one set for use of X.509 certificates [PKIX] and one for OpenPGP certificates [OpenPGP]. At the time of writing, TLS [TLS] standards are defined to use only X.509 certificates. This document specifies a way to negotiate use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. The proposed extensions are backward compatible with the current TLS specification, so that existing client and server implementations that make use of X.509 certificates are not affected.

RFC 5083: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type


This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type.

RFC 5084: Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)


This document specifies the conventions for using Advanced Encryption Standard-Counter with Cipher Block Chaining-Message Authentication Code (AES-CCM) and AES-Galois/Counter Mode (GCM) authenticated encryption algorithms as the content-authenticated-encryption algorithm with the Cryptographic Message Syntax [CMS] authenticated-enveloped-data content type [AuthEnv].

Google TechTalk om krypto

December 16th, 2007

Googles serie med inspelade presentationer från Googleplex är en guldgruva om man vill lyssna på intressanta föreläsningar.

En av dessa är en presentation om krypto i teori och praktik som Steve Weis höll i början av december. Steve tar bland annat upp en intro till modern krypto, hur man använder krypto i verkligen och då speciellt på Google.

Steve Weis är från MIT och ansvarar på Google för deras interna kryptobibliotek KeyMaster.

Slumptal, säkerhetsproblem, orsak och verkan

December 11th, 2007

(Mycket PRNG-prylar just nu…)

Den senaste tiden har det dykt upp flera nyheter om slumptalsgeneratorer. Mer specifikt brister i slumptalsgeneratorerna i olika operativsystem. De händelser detta handlar om utspelade sig för några veckor sedan och kan därför tyckas vara gamla. Men jag tycker att det är så intressant, inte minst utifrån hur problem hanteras att jag vill ta upp det ändå.

Först ett klargörande: Det handlar alltså om pseudoslumpgeneratorer (PRNG), dvs algoritmer som körs på vanliga datorer och som (när de fungerar korrekt) genererar en sekvens av värden.

Den genererade sekvensen av värden uppvisar ett slumpmässigt beteende, vilket kan testas, exempelvis med Marsaglias Diehard-test. En viktig egenskap (om man vill använda generatorerna för IT-säkerhet) är att en yttre observatör genom att studera N föregående värden inte skall kunna gissa kommande värden eller fler äldre värden.

Normalt sett implementeras dessa algoritmer med någon slags rent deterministisk tillståndsmaskin där startpunkten och sekvensen som genereras beror av ett startvärde (frö). Fröt skapas sedan genom att samla in vad som förmodas är äkta slump (fysisk entropi) från datorn och dess omgivningar.

Som källor för entropin används exempelvis positionen på hårddiskens huvud, tiden mellan tangentbordstryckningar, infångat brus från mikrofoner, temperaturen i processorn, hastigheten på fläkten, signaler på nätverksportar etc.

Så långt teorin, men i verkligheten visar det sig vara svårt både att designa och implementera dessa generatorer. Felaktigheter i slumptalsgeneratorn kan leda till problem som att den genererade sekvensen avviker från förväntad fördelning, att sekvensen går att prediktera eller att fröt går att extrahera genom att observera sekvensen.

Nåväl, tillbaka till berättelsen. Allt startade med artikeln Cryptanalysis of the Random Number Generator of the Windows Operating System av Leo Dorrendorf, Zvi Gutterman och Benny Pinkas med analys av slumptalsgeneratorn i Windows. Den (av mig nedkortade) sammanfattningen av artikeln lyder:


Abstract: The pseudo-random number generator (PRNG) used by the Windows operating system is the most commonly used PRNG. The pseudo-randomness of the output of this generator is crucial for the security of almost any application running in Windows. Nevertheless, its exact algorithm was never published.
...
We examined the binary code of a distribution of Windows 2000, which is still the second most popular operating system after Windows XP…. We analyzed the security of the algorithm and found a non-trivial attack: given the internal state of the generator, the previous state can be computed in $O(2^{23})$ work (this is an attack on the forward-security of the generator, an $O(1)$ attack on backward security is trivial). The attack on forward-security demonstrates that the design of the generator is flawed, since it is well known how to prevent such attacks.
...
The implication of these findings is that a buffer overflow attack or a similar attack can be used to learn a single state of the generator, which can then be used to predict all random values, such as SSL keys, used by a process in all its past and future operation. This attack is more severe and more efficient than known attacks, in which an attacker can only learn SSL keys if it is controlling the attacked machine at the time the keys are used.

Artikeln uppmärksammades på Slashdot och därmed var lavinen i gång med en massa turbulens, hetluft och spekulationer.

Plötsligt dök det upp problem även i andra slumptalsgeneratorer. Först ut var Linux där SecurityFocus rapporterade om Linux Kernel Random Number Generator Local Denial of Service and Privilege Escalation Vulnerability. Problemet fick stor uppmärksamhet och speciellt följande stycke hittar man på massor med webbplatser där de flesta hänvisar till en sida hos Neowin.net från vilken stycket ser ut att komma:


According to security researchers, the Linux kernel is prone to a local vulnerability that may result in a DoS or privilege escalation, possibly allowing the attackers to run arbitrary code on the target system. This issue stems from a stack-based overflow in kernel memory; if uccessfully exploited this issue allows local attackers to trigger kernel crashes and, in certain circumstances, also allows them to gain elevated privileges. However, the attacker may require partial administrative access via granular assignments of superuser privileges. Linux kernel versions prior to 2.6.22.3 are affected by this issue.

Försöker man hitta källan till problemet hamnar man på en commitlog för Linux. I den hittar man i sin tur CVE-2007-3105 som innehåller länkar och referenser till PaX-teamet, som verkar vara de säkerhetsforskare man refererar till.

Värt att notera är att Zvi Gutterman och Benny Pinkas dvs författarna till artikeln om analys av generatorn i Window tillsammans med Tzachy Reinman år 2006 publicerade en artikel med analys av generatorn i Linux.

Nästa generator på slaktbänken var FreeBSDs implementation av slumptalsgeneratorn Yarrow, som även den visade sig innehålla ett fel.

Att det visar sig finnas fel i slumptalsgeneratorer och vilka problem det kan leda till är intressant. Och än mer intressant, på vilka sätt felen och de uppkomna problemen hanteras. Det är på detta vi den senaste tiden fått många exempel på hur olika man kan agera.

Reaktionen från Microsoft dröjde några dagar (vilket är ok) och det första svaret från Microsoft var att problemet bara gällde Windows 2000, inte XP eller Vista. Detta uttalande fick man senare ändra på:


As recently as last Friday, Microsoft hedged in answering questions about whether XP and Vista could be attacked in the same way, saying only that later versions of Windows “contain various changes and enhancements to the random number generator.” Yesterday, however, Microsoft responded to further questions and acknowledged that Windows XP is vulnerable

(Min förstärkning av contain various changes and enhancements to the random number generator.)

Symantec hoppade in i leken och enligt Computerworld hävdade Symantec problemet inte var en sårbarhet utan ett designfel:


Symantec Corp., which posted its own analysis last week, issued a low-level alert for it today to customers of its DeepSight threat network. Like Microsoft, Symantec didn’t classify the threat as a security vulnerability, but instead called it a design error.

Microsoft’s recognized this as a local information disclosure issue, and Symantec agrees,” Wayne Periman, director of development for Symantec’s security response, said on Monday. “The reason for the low rating is that in order to exploit this, there has to be a complex attack organized.

(Återigen min förstärkning.)

Microsofts sätt att hantera situationen går att jämföra med hur FreeBSD agerade. I FreeBSDs fall leder felet till ett säkerhetsproblem, ett problem som noga beskrivs i den säkerhetsrapport (Security Advisory – SA) FreeBSD publicerade.


I. Background
The random(4) and urandom(4) devices return an endless supply of pseudo-random bytes when read. Cryptographic algorithms often dependon the secrecy of these pseudo-random values for security.

II. Problem Description
Under certain circumstances, a bug in the internal state tracking on the random(4) and urandom(4) devices can be exploited to allow replaying of data distributed during subsequent reads.

III. Impact
This could enable an adversary to determine fragments of random values previously read, allowing them to defeat certain security mechanisms. Note that the attacker has to be in close proximity to the source of the pseudo-randomness, which typically means local access to the system.

Jag har svårt att köpa Microsofts (och Symantecs) förklaring att det är ett designfel, inte ett säkerhetsproblem. Som jag ser det står inte designfel i motsatsförhållande till säkerhetsproblem, utan det är frågan om orsak och potentiell verkan. Designfel är en (av flera möjliga) orsak till att olika problem uppstår. Säkerhetsproblem är en typ av problem som kan uppstå.

Vidare blir jag rädd när man tonar ned just designfel. I min värld är designfel oftast mycket värre än ett implementationsfel. Implementationsfel kan vara ett skrivfel eller en miss – men ett designfel handlar om feltänk. Typiska designfel är protokoll som visar sig inte fungera – och att byta ut protokoll är ingen enkel sak. Som en god vän brukar uttrycka det: Trasigt.

Tittar man i den officiella källkodspatchen för felet i FreeBSD ser man att programmeringsfelet är en enradare:

--- sys/dev/random/yarrow.c27 May 2007 18:54:58 -00001.47
+++ sys/dev/random/yarrow.c27 Nov 2007 17:17:29 -0000
@@ -296,6 +296,7 @@

random_state.outputblocks = 0; } retval += (int)tomove;
+cur = 0; } } else {

Dvs en räknare (cur) nollställdes inte på ett korrekt sätt i ett IF-fall. Känns som ett typiskt implementationsfel.

En annan sak som skiljer mellan de senaste tidens fel i PRNG:s är hur man publicerar åtgärderna. FreeBSD och Linux publicerar patchar, och som de öppen/fri-kod-projekt de är finns naturligtvis hela koden på nätet. Vill man kan man exempelvis titta på hela koden för implementationen av Yarrow i FreeBSD.

Microsoft å sin sida hävdar alltså att man utfört various changes and enhancements to the random number generator. Denna formulering ger inte mig en speciellt stark känsla av förtroende, inte minst då man först hävdar att Windows XP inte är sårbar, och sedan kommer fram till att det är den i alla fall. Har man inte koll på vilka various changes and enhancements man petat in i vilket OS?

Beroende på hur problemen i slumptalsgeneratorn yttrar sig och hur access till generatorn eller den sekvens den genererar går det i vissa fall att attackera ett system. Ett klassiskt exempel på en attack mot en slumptalsgenerator var den attack som Ian Goldberg och David Wagner utförde mot en tidig version av SSL i webbläsaren Netscape.

I fallet med Linux och FreeBSD konstaterar projekten alltså att de problem som kan uppstå öppnar upp för olika typer av attacker. I Microsofts fall säger alltså Symantec att attacken skulle vara så komplex att dom bedömer att det inte är något hot, och som tredje, rätt kompetent part bör vi kanske lita på Symantec.

Den sista aspekten på skillnaderna mellan hur de olika OS:en agerar vad gäller sina PRNG:s är information om vilken algoritm de använder. FreeBSD och Linux är som sagt öppen/fri-kod. Men tittar man på OpenSolaris från Sun eller Apple så hittar man även här information och källkod för PRNG-funktionerna.

MacOS X Leopard/Darwin 10.5 använder precis som FreeBSD en implementation av Yarrow. motsvarande kod hittar man i darwinsource/10.5/xnu-1228/bsd/dev/random. Jag är inte helt säker på att jag hittar motsvarande ställe i källkoden som i FreeBSD, men jag ser inte samma problem som i FreeBSD – uppenbarligen är det en helt separat implementation av Yarrow, vilket innebär att dom skulle kunna designfel, men antagligen inte implementationsfel. Det viktiga är dock att jag kan gå in och titta på koden, och tom kompilera och testa.

Vi vet inte (iaf lyckas inte jag hitta någon information om) vilka generatorer som Microsoft använder i sina OS. Vad bygger den på för principer? Vilka designval har man gjort? Hur har man testat implementationerna? Och (återigen) vad innebär various changes and enhancements.

Speciellt intressant i fallet Microsoft är att Niels Ferguson, en av skaparna av Yarrow/Fortuna faktiskt jobbar på Micrsosoft. Har han varit med och byggt om PRNG:n? Varför berättar man inte det? Det skulle iaf få lite cred hos mig (om det nu är värt något.)

Microsoft kör inte med egna krypton, ex en icke-kompatibel version av AES. Däremot har man stukat till Kerberos, hittat på egna autenticieringsmekanismer (NTLM) och ibland samarbetat med andra för utveckling av tunnelprotokoll (PPTP). Varför och i vilka tillfällen Microsoft bestämmer sig för att utveckla eget är för mig en gåta. Vad vinner man på att hacka sin egen PRNG?

Kontentan av allt det här är som jag ser det att:

  1. Bygga PRNG:s – både design och implementation är svårt, så varför hacka en egen?

  2. Det skiljer fundamentalt i hur man agerar när det dyker upp ett fel

  3. Det är skillnad på fel och problem

Test av Yubicos kodgenerator

December 11th, 2007

Jag har precis testat (lekt en stund) med en kodgenerator från svenska Yubico.

Yubico

Den version av YubiKey jag testat är YubiKey Spin.

YubiKey Spin

Enheten ser ut som ett litet USB-minne. Men när jag kopplade in den ville MacOS X att jag skulle hjälpa till att identifiera det okända USB-tangentbord jag precis pluggat in. Eftersom enheten bara har en knapp var det inte så lätt att trycka på de knappar OS:et ville att jag skulle trycka på. Men när jag tryckt på den knapp som finns kom OS:et fram till att den inte kunde identifiera tangentbordet, och enheten sattes helt enkelt till ett generiskt tangentbord.

Och det är precis det här som är det fina i kråksången. Sett från OS:et identifierar och beter sig USB-nyckeln verkligen som om den vore ett tangentbord. Detta blir än mer uppenbart när man startar upp en editor och trycker några gånger på knappen. Vad som kommer ut ser ut ungefär så här:

deaddeadeadgikuhnitkbifdlhgcnjkejbngcvubbft
deaddeadeaditcielkughinkgcnjfrjcnvhlbfbggtg
deaddeadeadjkvrberittikdvereibehjkfrtgrdilf
deaddeadeadndvivdenteuguuncbfrcvjtjjbkchfin
deaddeadeadcuutgtrjjftbknefuindldnbkvkteiiu
deaddeadeadjkhgnvhthubfefintcjdulfhdfbltdvv
deaddeadeadcchggdvjjlrburhklhchbriivefcklvf
deaddeadeaddlgunlnrkctkiehfeujvhccgvtnbfjtb
deaddeadeadvnjuifetlthgedlktuhickehrkicckcf

Varje gång man trycker på knappen kommer det ut en sträng på 44 tecken. Strängen består av en inledande del om 12 tecken som uppenbarligen är en ID-del och sedan 32 tecken som förhoppningsvis representerar värden från en bra rektangelfördelning. (I texten ovan har jag ersatt ID-delen med en fejkad del.)

Det tar enheten runt en sekund att generera en sträng. Inte blixtsnabbt, men mycket snabbare man hinner skriva av koden i ett LCD-fönster.

Vad gäller säkerheten skriver Yubico på sin webbplats om algoritmen som används att:


Apart from present hardware authentication tokens, YubiKey does not rely on a two-way challenge-response protocol, battery-powered time base, keyboard or a display.

Yet, how can a device be so secure when four of the most common security measures present in state-of-the-art authentication devices have been removed?

The YubiKey generates a truly unique 128-bit code at each authentication event and there is no time window during which two authentication codes are equal. All of the unique 128-bit code is encrypted with AES-128 and is then encoded to “readable form”, where the resulting string is transmitted in its full length.

The main components of the unique code comprise:

1. A hidden identity field to verify the decrypted result to a non-published identity. 2. A volatile counter is incremented by one for each code that has been generated. This code is reset at each power-up. 3. A non-volatile counter is incremented by one for each power-up event. The value of this counter is preserved even when power is lost. 4. A non-predictable counter value is fed by a time-base that is highly device and session dependent. Together with a server-based authentication module, this counter can provide a strong protection against “Phishing” attempts. 5.A random seed. 6.A cryptographic checksum.

Together, these fields form a 128-bit value and provide a higher number of combinations than a 3 followed by thirty-eight zeroes. Combined with a further encryption using AES-128 and the fact that a hacker has no information about the plaintext, cryptanalysis is futile.

Det låter bra. Det hade dock varit spännande att läsa en bra analys på algoritmen och veta mer om hur dom använder AES (ex vilken kryptomod) samt gärna sett resultatet av mangling av genererade koder i Marsaglias Diehard-tester.

Enligt Yubico skall nyckeln även kunna fånga upp Caps Lock-tryckningar vilket skall göra att man kan få en kod genererad bara genom att snabbt trycka två gånger på det vanliga tangentbordets Caps Lock-tangent. Detta fick jag dock inte att fungera, vilket antagligen har att göra med vilket generiskt tangentbord som enheten fick som profil.

Detta är knappast ett fullödig test, men mina första intryck är att Yubico användningsmässigt sett tänkt helt rätt. Funkar säkerheten är YubiKey en riktigt smart liten kodgenerator, ex för identifiering på OpenID-webbplatser.

ioctlizer en Win32 IOCTL-fuzzer

December 10th, 2007

Jag har tidigare bloggat ett par gånger om fuzzing. Justin Seitz har släppt en ny fuzzer som arbetar på med ioctls:


ioctlizer is an attempt at fuzzing Windows IOCTL requests. It is split into two separate tools, ioctltrap.py and ioctlizer.py.

ioctltrap – used to spawn or attach to a user-mode process that interacts with a device (i.e. wireshark.exe). By hooking the Win32 system calls that are required to interact with a device driver, it builds a global test case list to be used when fuzzing the device(s).

ioctlizer – used to import the trapped IOCTL/Read/Write test cases, and begin mutating them. Easily extended mutators, as only the most basic of mutations is included in the fuzzer itself.

För mer information se ioctlizers sida på Google Code, eller ladda ner koden till ioctl.

Interpellation om IT-säkerhet

December 10th, 2007

Riksdagsledamot Désirée Liljevall (S) har skrivit en intressant interpellation om IT-säkerhet.
Désirée Liljevall

2007/08:278 Nationell Internetsäkerhet


av Désirée Liljevall (s)

till statsrådet Åsa Torstensson©

Sverige är en stolt IT-nation. Vi har en hög andel hushåll med Internetuppkopplade datorer, myndigheterna ger service och information på nätet dygnet runt och den tekniska utvecklingen gör att allt fler har tillgång till snabbt, eller till och med mycket snabbt, bredband. Internet som arbetsverktyg är väl använt av människor i alla delar av samhället. Det här är en positiv utveckling. Desto allvarligare är det att larmrapporterna om dålig IT-säkerhet hörs allt oftare. Kunskapsbristen om vikten av Internetsäkerhet är skriande. Riksrevisionen kom med en rapport i ämnet i juni, Krisberedskapsmyndigheten har rapporterat i frågan ett par gånger i höst. Svenska myndigheter är inte samordnade, de har undermåligt skydd och de anställda vet för lite hur de ska agera för att skydda sina IT-system och den information de har.

För en enskild datoranvändare räcker det med ett klick på ”fel” länk i ett e-postmeddelande eller på en hemsida för att datorn ska bli kapad och hamna i ett så kallat botnet. Via dessa nät av tusentals datorer kan kriminella skicka spam, störa hela IT-system, stjäla information och så vidare. Eftersom datorerna finns i många olika länder är det svårt att hitta de kapade datorerna för att bromsa utvecklingen och komma åt brottslingarna.

En organiserad Internetattack skulle kunna slå ut stora delar av vårt samhälle. Det mest kända exemplet på hur informationssäkerheten i ett helt land äventyras är när Estland i våras beslutade att flytta en staty från andra världskriget från en plats i Tallinn till en annan. Landets regeringskansli, flera myndigheter och riksmedierna utsattes då för organiserade överbelastningsattacker. Sverige har mycket dålig beredskap för att skydda sig från en sådan attack.

Mot bakgrund av vad som anförts undrar jag vad statsrådet tänker göra för att skydda svenska myndigheters IT-system från Internetattacker.

Désirée Liljevall har uppenbarligen läst på, gissningsvis bland annat rapporten Sveriges beredskap mot nätangrepp som KBM presenterade i slutet av november. Det skall bli spännande att se vad Åsa Torstensson svarar på interpellationen. Den är så bra att jag verkligen hoppas att den inte avfärdas utan tas på allvar av ministern.