I Cryptech-projektet arbetar vi mycket just nu med att utveckla och testa olika entropikällor som kan användas för att driva slumptalsgeneratorn. En viktig del i arbetet är att kunna bedöma hur väl entropikällan fungerar – under normala förhållanden och när den är utsatt för försök till manipulation.

Det finns flera olika verktyg och standarder för att undersöka kvalitet på slumptal. Ett av det mest omfattande verktygen är Dieharder. Dieharder inkluderar en stor uppsättning av tester och tar lång tid att köra. Ett enklare och snabbare verktyg är Ent. Ent gör en skattning på mängd entropi per bit, försöker komprimera indatat, beräknar median-, och medelvärden m.m. Att använda Ent går mycket snsnabbt och ger en bra första skattning. Testar jag på en av mina entropikällor jag byggt inne i en FPGA får jag exempelvis:

pluttis:data js$ ent filtered_fpga_entropy_2014-06-10.bin
Entropy = 7.961751 bits per byte.

Arithmetic mean value of data bytes is 127.5067 (127.5 = random).
Monte Carlo value for Pi is 3.079589263 (error 1.97 percent).
Serial correlation coefficient is -0.004758 (totally uncorrelated = 0.0).


Utifrån Ent verkar det ganska bra… Men ett ännu snabbare test är att faktiskt titta på de genererade värdena. Människan är ganska bra på att se mönstrer i bilder. För att snabbt ta en fil och omvandla den till en bild satte jah ihop verktyget view_rnd.

Programmet view_rnd är byggt i Python och använder PIL/Pillow för att skapa biblioteket. Genom att använda bytevärdena i källfilen som gråskalenivåer skapas bilder som ger en visuell representation av innehållet. Så här ser exempelvis bilden för datafilen som testades med Ent ovan ut:

Bild skapad med entropikälla inne i en FPGA.

Det syns inga tydliga regelbundna mönster. Däremot finns det lite bågar och punkter i bilden. Samtidigt kan mönster uppkomma bara igenom att indata organiserad i en 2D-struktur. Dimensionerna man väljer ger viss påverkan. I programmet gör jag det enkelt för mig och skapar kvadratiska bilder utifrån storleken på indatafilen. En sak man inte ser enkelt är generella nivåer, dvs om indatat spänner bara innehåller värden inom en del av värderymden [0..255]. Det ser man exempelvis på följande lilla bild där indata är programmet skälv som alltså är en textfil:

Bild för källkoden till view_rnd.

För att ha något att testa mot inkluderar view_rnd även ett par testlägen där den antingen använder slumptalsgeneratorn i Python eller slumptalsgeneratorn (PRNG) beskriven i boken Numerical Recipies in C. Den senare generatorn genererar värden som innehåller en hel del mönster:

Bild skapad med värden genererade med generatorn från Numerical Recipies in C.

Kasper Ingelvide har testat olika slumptalsgeneratorer i C++11:s standardbibliotek (pseudoslumptalsgeneratorer – PRNG). Kasper skrev ett program som genererade data med de olika generatorerna och skapade bilder med view_rnd. I flera av dessa synns klara mönster:

Data skapad med generatorn Mersenne Twister 19937.

Generatorn baserad på Mersenne Twister ger en fin figur utan uppenbarliga mönster.

Data skapad med generatorn ranlux24.

I bilden för ranlux24 finns tydliga ränder där värdena generellt har lägre nivå – en bias.

Tack till Kasper för att bygga programmet och testa view_rnd.

Det fria kryptobiblioteket GNU Nettle har släppts i version 3.0. Nettle är ett lågnivåbibliotek som inkluderar ett stort antal kryptofunktioner för att symmetriska, asymmetriska operationer, hashfunktioner, nyckelhantering, slumptal m.m. Nettle har genom alla år noggrant och stringent utvecklats och underhållits av dess skapare Niels Möller. Är du i behov av GPL-licensierade kryptofunktioner är Nettle ett av de bästa alternativen.

En del av funktionerna i Nettle har kompletterande implementationer i assembler för arkitekturerna arm, sparc och x86 i olika varianter. Niels Mäller har även med stöd från Internetfonden utvecklat funktioner i Nettle anpassade för inbyggda system med begränsade resurser.

Secworks Joachim Strömbergson har bidragit till Nettle genom att hjälpa till att implementera strömkryptot ChaCha, samt genom att komplettera implementationen av SHA2-algoritmerna till att även stödja SHA-512/224 och SHA-512/256 som definieras i NIST FIPS 180-4.

Version 3.0 inkluderar ett flertal nya funktioner och ändringar. Hela ändringslistan ser ut som följer:

Interface changes:

* For the many _set_key functions, it is now consider the
normal case to have a fixed key size, with no key_size
arguments. _set_key functions with a length parameter are
provided only for algorithms with a truly variable keysize,
and where it makes sense for backwards compatibility.

INCOMPATIBLE CHANGE: cast128_set_key no longer accepts a key
size argument. The old function is available under a new
name, cast5_set_key.

INCOMPATIBLE CHANGE: The function typedef
nettle_set_key_func no longer accepts a key size argument.
In particular, this affects users of struct nettle_cipher.

* The nettle_cipher abstraction (in nettle-meta.h) is
restricted to block ciphers only. The encrypt and decrypt
functions now take a const argument for the context.

INCOMPATIBLE CHANGE: nettle_arcfour, i.e., the nettle_cipher
abstraction for the arcfour stream cipher, is deleted.

INCOMPATIBLE CHANGE: New type, nettle_cipher_func, for the
encrypt and decrypt fields of struct nettle_cipher.

* New DSA interface, with a separate struct dsa_param to
represent the underlying group, and generalized dsa_sign and
dsa_verify functions which don’t care about the hash
function used. Limited backwards compatibility provided in
dsa-compat.h.

INCOMPATIBLE CHANGE: Declarations of the old interface,
e.g., struct dsa_public_key, dsa_sha1_sign, etc, is moved to
dsa-compat.h.

INCOMPATIBLE CHANGE: The various key conversion functions,
e.g., dsa_keypair_to_sexp, all use the new DSA interface, with
no backwards compatible functions.

INCOMPATIBLE CHANGE: dsa_generate_keypair also uses the new
interface. dsa-compat.h declares a function
dsa_compat_generate_keypair, implementing the old
interface, and #defines dsa_generate_keypair to refer to
this backwards compatible function.

* New AES and Camellia interfaces. There are now separate
context structs for each key size, e.g., aes128_ctx and
camellia256_ctx, and corresponding new functions. The old
interface, with struct aes_ctx and struct camellia_ctx, is
kept for backwards compatibility, but might be removed in
later versions.

* The type of most length arguments is changed from unsigned
to size_t. The memxor functions have their pointer arguments
changed from uint8_t * to void *, for consistency with
related libc functions.

* For hash functions, the constants *_DATA_SIZE have been
renamed to *_BLOCK_SIZE. Old names kept for backwards
compatibility.

Removed features:

* The nettle_next_prime function has been deleted.
Applications should use GMP’s mpz_nextprime instead.

* Deleted the RSAREF compatibility, including the header file
rsa-compat.h and everything declared therein.

* Also under consideration for removal is des-compat.h and
everything declared therein. This implements a subset of the
old libdes/ssleay/openssl interface for DES and triple-DES,
and it is poorly tested. If anyone uses this interface,
please speak up! Otherwise, it will likely be removed in the
next release.

Bug fixes:

* Building with ./configure –disable-static now works.

* Use GMP’s allocation functions for temporary storage related
to bignums, to avoid potentially large stack allocations.

* Fixes for shared libraries on M$ Windows.

New features:

* Support for Poly1305-AES MAC.

* Support for the ChaCha stream cipher and EXPERIMENTAL
support for the ChaCha-Poly1305 AEAD mode. Specifications
are still in flux, and future releases may do incompatible
changes to track standardization. Currently uses 256-bit key
and 64-bit nonce.

* Support for EAX mode.

* Support for CCM mode. Contributed by Owen Kirby.

* Additional variants of SHA512 with output size of 224 and
256 bits. Contributed by Joachim Strömbergson.

* New interface, struct nettle_aead, for mechanisms providing
authenticated encryption with associated data (AEAD).

* DSA: Support a wider range for the size of q and a wider
range for the digest size.

Optimizations:

* New x86_64 assembly for GCM and MD5. Modest speedups on the
order of 10%-20%.

Miscellaneous:

* SHA3 is now documented as EXPERIMENTAL. Nettle currently
implements SHA3 as specified at the time Keccak won the SHA3
competition. However, the final standard specified by NIST
is likely to be incompatible, in which case future releases
may do incompatible changes to track standardization.

* The portability fix for the rotation macros, mentioned in
NEWS for 2.7.1, actually didn’t make it into that release.
It is included now.

* cast128_set_key rewritten for clarity, also eliminating a
couple of compiler warnings.

* New command line tool nettle-pbkdf2.

När man arbetar med att analysera binärfiler (ett kompilerat program) behöver man en ett verktyg som kallas en disassembler. En bra disassembler kan inte bara översätta binären till assemblerinstruktioner utan även visa anrop, hantera kod för olika arkitekturer etc. Det finns egentligen bara två stora disassemblers. OllyDbg är en disassembler som körs i Windows. Olly är gratis, rätt kompetent men med ett relativt enkelt (för att inte säga fult) gränssnitt.

Användargränssnittet för OllyDbg.

Den andra disassemblern är Ida Pro. Ida kan vrida och ända på en binär på ett otal sätt, kommer med ett batteri av analysfunktioner, går att scripta och har stöd för massor med olila arkitekturer. Snyggt gränssnitt gör Ida lättarbetat. Enda haken med Ida är att det kostar rätt mycket pengar. Billigaste versionen kostar strax under 600 USD.

Ida Pro i all sin glans.

Jag har än så långe inte känt att jag har råd att skaffa Ida. Istället har jag fått köra Olly i en virtuell maskin (jag kör normalt OSX, FreeBSD eller Linux som OS på mina maskiner.). Jag har därför letat efter en bra disassembler som går att köra i OSX eller Linux. Och nu finns det.

Hopper är en disassembler som funktions- och kapacitetsmässigt lägger sig mellan Olly och Ida. Hopper stödjer flera olika arkitekturer (x86 i ett antal varianter, olika versioner av ARM inklusive ARM64). Hopper kan disassemblera iOS-binärer och kan generera pseudokod i både C och Objective-C. Det finns även en debug-server som gör att man kan debugga en exekverande applikation med Hopper. Och Hopper har ett (anseer jag) snyggt och lättarbetat gränssnitt.

Hoppers gränssnitt. Notera pseudokod och anropsgrafen.

Hopper är inte gratis, men priset är ungefär en tiondel av Ida vilket gör den klart mer rimlig. Jag har inte använt Hopper tokmycket än, men det lilla jag har använt den har gjort att jag är mycket nöjd. Jag kör inte längre Olly och överväger inte heller att sälja en njure för att få råd med Ida.n För ett bra exempel på hur man kan arbeta med Hopper finns en utmärkt beskrivning (och film) av Melissa Elliott (0xabad1dea) när hon analyserar en binär med Hopper.

Om du kör Linux eller OSX och bootar upp Windows bara för att köra Olly tycker jag du ska ta dig en titt på Hopper.

Det har publicerats ett par artiklar om HSM-projektet Cryptech som Secworks abetar med.

IDGs TechWorld skrev en artikel om hur Öppen hårdvara ska rädda nätsäkerheten där Secworks Joachim Strömbergson är intervjuad. Artikeln ger lite bakgrund till projektet och vad vi försöker åstadkomma rent tekniskt.

För en vecka sedan publicerade tyska Heise en artikel om Cryptech som bygger på en intervju med projektets Randy Bush. Den här artikeln har lett till klart ökat intresse och aktivitet på projektets maillistor.

Grunden av mycket av säkerheten på Internet i dag hänger på tillgången till bra slumptal som används tillsammans med ett några olika kryptografiska algoritmer för att skydda exempelvis skydda DNS-systemet, routing samt säker inloggning på webbplatser och datorer. På grund av förra årets många avlöjnanden om massavlyssning och försök till manipulation av de säkerhetsmekanismer vi tror oss kunna lita på sker i dag en stor omvärdering av vad som går att lita på. Funktioner med dålig transparens och med liten möjlighet att verifiera och funktionaliteten har i dag svårt att få tillit.

För algoritmer som AES, SHA-256 och RSA pågår diskussioner om vad som går att lita på, men då algoritmerna är öppet definierade och en given implementation oftast går att verifiera är dom fortfarande betrodda. Men när det kommer till nyckeln i säkerheten – slumptalen är det sämre ställt. Oftast genereras dessa slumptal och nycklar med en så kallad HSM – en High Security Module (eller Hardware Security Module). Detta är bokstavligt talat svarta lådor med aktiva skalskydd som hindrar någon att öppna dom.

Ett exempel på en HSM – ett PCIe-kort från SafeNet med en svart låda där säkerhetsfunktionerna bor.

Leverantörerna av dessa maskiner lovar att dom fungerar som dom ska och maskinerna oftast validerade enligt säkerhetsstandarder som NIST FIPS 140-2 (ofta nivå fyra) och Common Criteria. Men kan man lita på att det innebär att maskinerna gör vad som utlovas (och bara det)?

Vi vet i dag att det skapas och genereras nycklar som är mycket sämre än vad man kan förvänta sig. Förra året publicerades en undersökning av certifikat med RSA-nycklar som används i ID-kort i Taiwan. Korten har blivit certifierade av NIST i USA, CSE i Kandada sam en godkänd CC-evaluering i BSI i Tyskland. Trots detta kunde ett forskarteam med bland annat Tanja Lange, Nadia Heninger och Daniel J Bernstein visa att nycklarna på korten är dåligt skapade, att det finns gemensamma primtal i flera av certifikaten och att det går att forcera säkerheten. Inte alls bra.

I ett försök att förbättra säkerheten runt nyckelgenerering och inte minst möjligheten att skapa tillit till HSM:er har det startats ett internationellt projekt för att ta fram en öppen HSM-plattform. Projektet heter Cryptech och Secworks är stolta över att vara med i projektet och arbetar aktivt för att utveckla plattformen.

Syftet med projektet är att få fram de komponenter, verktyg och dokumentation som gör det möjligt för att vem som helst själv ska kunna (eller be någon annan dom litar på) att plocka ihop en HSM dom kan verifiera fungerar som förväntat och därmed kunna lita på. Målet är alltså inte en färdig applikation eller en hårdvaruburk. Däremot kommer vi att ta fram referensimplementationer som mer eller mindre direkt går att använda. Och eftersom alla kod och designunderlag är öppna kan vem som helst som vill faktiskt bygga och sälja färdiga HSM:er baserat på Cryptech. (Koden som utvecklas för Cryptech kommer att vara BSD-licensierad och all dokumentation kommer att vara Creative Commons-licensierad.)

Det finns många fundamentala utmaningar att brottas med i projektet – inte minst hur man skapar öppen hårdvara implementerad i FPGA- eller ASIC-teknik där det finns spårbarhet och kontroll genom verktygsflödet. Att få kontroll på sidokanaler i olika former kräver både kompetens och tekniska resurser som projektet inte har i dag. Men det hindrar oss inte ifrån att försöka.

Just nu pågår mycket arbete med att etablera de första hårdvaruplattformarna för att kunna göra verifiering på verklig hårdvara. I dag används utvecklingskort från TerasIC med Alteras Cyclone IV- och Cyclone V-familjer. Just i dag sker exempelvis verifiering subsystemet för hashfunktioner (med SHA-1 och SHA-256) på ett TerasIC C5G-kort:

TerasICs C5G-kort som via USB pratar med ett värdsystem för att testa hashimplementationer.

Samtidigt pågår både ett underökande arbete, diskussioner och början till definition av pudelns kärna – slumptalsgeneratorn. Vilken eller vilka entropikällor ska vi stödja, hur ska insamling av entropi ske, vilken CSPRNG ska vi använda, hur skapar man transparens i en slumptalsgenerator etc? Många frågor med många möjliga svar och följdfrågor blir det.

Under 2014 ska en första prototyp till HSM tas fram. Och för att driva utvecklingen har en liten uppsättning av användningsfall definierats. Bland annat ska man kunna använda Cryptech i RPKI och DNSSEC. Men detta är inte de enda användningsfall som Cryptech ska kunna stödja. Och vi är mycket intresserade av att höra vilka andra behov som finns. Inte minst är detta viktigt för att definiera bra gränssnitt mot lägre lagers säkerhetsfunktioner. Vilka anrop och datastrukturer krävs för att effektivt kunna använda Cryptech är mycket viktigt att få koll på.

Funktionalitet som kommer att finnas i slutet av 2014 är bla RSA (nyckelgenerering, kryptering/dektyptering, signering/verifiering) med minst 4096 bitars nyckel, en fullt fungerande TRNG, en säker nyckellagring samt symmetrisk med minst AES samt några olika moder. Cryptech är dock inte i första hand en kryptoaccelerator som ger hög prestanda, utan det är säkerhet, kontroll och tillit som är det viktiga. För att kunna prata med applikationer kommer det bland annat att finnas PKCS#11-interface. Det är ambitiöst, men genomförbart tror vi.

Har du frågor och tankar om Cryptech så posta dom gärna här eller på twitter. Men ännu bättre är att posta dom till Cryotechs tech-lista. Listan är öppen för alla. Projektet är öppet och transparent. Alla commits som sker in i projektets repo är exempelvis signerade så att det går att spåra vem som gjort en föränding.

Så, detta blev en ganska lång text. Det finns massor mer att skriva men vi kommer att löpande skriva mer om Cryptech och Secworks arbete i projektet så det är inte slut med det här. Men att det är ett otroligt roligt och spännande projekt kan vi iaf avslöja.

Efter många diskussioner har de olika förslagen (drafts) för att få in ett nytt strömkryto i TLS nu kombinerats till ett förslag. draft-mavrogiannopoulos-chacha-tls definierar nu kryptosviter för TLS som anvönder ChaCha med 20 iterationer i kombination med HMAC-SHA1 respektive Poly1305 som MAC-funktionalitet. Förhoppningsvis kan det sammanslagna förslaget enklare accepteras så att vi kan få igenom ett nytt strömkrypto i TLS och underlätta pensioneringen av RC4.

Nu finns det en uppdaterad hårdvaruimplementation av strömkryptot ChaCha från Secworks. Den nya versionen använder fyra parallella QR-moduler istället för en enda modul i den första versionen av implementationen.

I en Altera Cyclone IV GX ökar prestandan från 870 Mbps till 2,6 Gbps och detta med endast 5% mer hårdvaruresurser.

Skälet till detta är att den ARX-konstruktion (Addition, Rotation och XOR) som utgör kärnan i kryptot och finns i QR-modulen implementeras effektivt i FPGA-strukturen. Detta gör att den ökande mängden logik för de tre nya QR-modulerna i stort sett kompenseras av minskad logik för att välja ut operander (MUX-ar) till den enda QE-modulen. Motsvarande resultat såg vi när vi byggde ut hårdvaruimplementationen av den nyckelstyrda hashfunktionen SipHash från en till fyra parallella ARX-enheter. Men för SipHash minskade till och med totala antalet resurser.

Prestandamässigt ökade inte prestandan fyra gånger utan bara drygt tre gånger. Skälen till detta är att klockfrekvensen minskade något men även att det finns några cykler för att initiera och avsluta processningen. Dessa cykler går inte att parallellisera bort och tar allt större del av den totala latenstiden ju mer QR-processningen parallelliseras.

Det skulle gå att utöka till åtta stycken QR-moduler. Men detta skulle skapa direkta beroenden mellan par av QR-moduler och totala logikdjupet skulle fördubblas. Eftersom den längsta logikvägen går genom QR-modulerna innebär en sådan parallellisering att klockfrekvensen närmast skulle halveras. Resulatet skulle troligen bli en marginellt förbättrad prestanda. Samtidigt skulle det maximala klockfrekvensen bli så låg att implementationen skulle bli svår att använda i konstruktioner utan att bli den modul som begränsar klockfrekvensen för hela konstruktionen.

Implementationen av ChaCha har självtestande testbänkar och i kombination med bra revisionshantering (Git i kombination med Github) har det varit lätt och smidigt att utifrån en första fungerande enkel implementation stegvis bygga ut implementationen för att nå bättre prestanda. Detta utan att riskera att den tidigare versionen inte går sönder. I värsta fall får man köra git checkout på en fil man försökt ändra och börja om.

Lagom till jul är första versionen av Secworks öppna hårdvaruimplementation (en soft core) av strömkryptot ChaCha färdigt. Implementerad i en krets från Alteras FPGA-familj Cyclone IV GX krävs 5628 logikelement (LEs) och 3629 register. En stor del av dessa, inte minst registren härör dock från det 32-bitars gränssnitt som implentationen är utrustad med och som gör det möjligt att dubbelbuffra data så att det går att skriva in ny data samtidigt som föregående block av 64 Bytes processas.

Prestandamässigt når implementationen drygt 60 MHz i Cyclone IV GX vilket ger 870 Mbps rå kryptoprestanda. Den här versionen av implementationen innehåller inga parallella quarterrounds. Vi kommer att lägga till versioner med upp till minst 4 quarterrounds vilket bör lyfta prestandan rejält.

Implementationen som är BSD-licensierad finns att klona på github.

Med detta önskar Secworks en god Jul och ett gott nytt år!

Sprang i dag på ett mycket intressant ramverk för att bygga disassembleringsprogram, dvs program som på olika sätt plockar i sär och analyserar binärfiler fär olika arkitekturer.

Ramverket heter Captstone och släpptes precis i 1.0-version. Capstone kan analysera och disassemblera binärfiler för ARM, ARM64 Mips och x86. Här finns en mer detaljerad lista över varianter på arkitekturer som stödjs. Capstone är alltså inte en debugger eller interaktiv disassemblator som IDA eller OllyDbg.

Däremot kan man använda Capstone för att bygga program som analyserar binärer. Program som kan vara interaktiva. Capstone används bland annat i verktyg för att analysera skadlig kod (eng: malware) exempelvis pyew och radare. Andra användningsområden är att bygga verktyg för att underlätta optimering av kod genom att ta fram användning av olika instruktioner, register m.m. Capstone är skrivet i C men kommer med wrappers för Python (Python2), Ruby, OCaml, C#, Java och Go.

Capstone är BSD-licensierat och är enkelt att installera och komma igång med. Jag testade att klona Capstone-repot samt bygga och installera bibliotek och Pythonwrappers. Följande exempel (från Capstone) visar ett enkelt program som tar in en binär och disassemblerar:

Capstone är inte det enda bilioteket av den här sorten. När jag kollade runt hittade jag bland annat udis86. Men Capstones förmåga att analysera binärer för många arkitekturer och dess (i mitt tycke) rena API och wrappers till högnivåspråk gör Capstone för mig högintressant. Riktigt kul och som det verkar riktigt bra.

Just nu pågår det ett antal diskussioner på olika maillistor och forum om slumptalsgeneratorer. Bakgrunden är det senaste årets alla avslöjanden som skapat frågor om vilka säkerhetsmekanismer vi egentligen kan lita på. Att mekanismerna fungerar som vi tror och ger den säkerhet vi förväntar oss.

Slumptalsgeneratorer är på många sätt basen för all säkerhet. Slumptals används som salt i lösenordsdatabaser, som start för sessionsnummer, ID i databaser (för att undvika DoS-attacker, se ex denna postning om SipHash). De nycklar vi använder för symmetrisk kryptering samt äkthetskoder (MAC) måste vara slumptal av bra kvalitet så att ingen kan gissa dom. Och för att vi ens ska kunna göra ett bra Diffie-Hellman-nyckelutbyte måste vi också ha tillgång till bra slumptal.

Samtidigt är bra, riktiga slumptalsgeneratorer svåra att konstruera och kontrollera. Dessa generatorer kräver tillgång fysiska slumpmässiga processer från vilka entropi samlas in. Dessa processer ska ge mycket entropi, vara billiga och enkla att integrera i digitala system. Och inte vara känsliga för extern manipulation. Ingen lätt kombination. Lägg dessutom till att vi vill att hela kedjan från den fysiska processen till genererade slumptal ska vara transparent och kontrollerbar från en godkänd undersökare blir det hela än mer komplicerat.

Den insamlade entropin används sedan för att initiera en algoritm, en kryptografiskt säker pseudoslumptalsgenerator (Cryptogtphically Safe Pseudo Number Random Generator – CSPRNG). Det är denna algoritm som sedan genererar en mängd med slumptal varefter generatorn initieras om med annan insamlad entropi.

Processortillverkarna Via och Intel har integrerat slumptalsgeneratorer i sina chip. I Vias fall finns det vissa möjligheter att titta på rådatan som samlas in från den integrerade entropikällan. Men i Intels fall finns ingen motsvarande möjlighet. Det går att testa att den CSPRNG som används fungerar enligt specifikation, men det går inte att se varifrån indata – entropin egentligen kommer ifrån. (Jag har tidigare skrivit om Intels slumptalsgenerator Bull Mountain (artikel ett, artikel två) och att jag ser den som ett stort steg framåt för säkerheten. Det tycker jag till viss del fortfarande. Men då i första hand som entropikälla, inte som ersättare för hela slumptalsgeneratorn.)

Avsaknaden av transparens gör att flera nu aktivt letar efter alternativ samt nya sätt att förhålla sig till dessa generatorer. Utvecklarna av operativsystemet FreeBSD har gått ut och sagt att dom inte kommer att använda generatorerna direkt utan använda dom som entropikällor där dom matar CSPRNG:n Yarrow. Äveb bland Linuxytvecklare för stora diskussioner om huruvida RdRand (Intels instruktion för att läsa från slumptalsgeneratorn) ska användas som komplett generator, som entropikälla eller inte alls.

Ett problem med RdRand som entropikälla är att den har mycket stor kapacitet (den kan lätt generera Gbps) och om ytterligare en entropikälla används, men denna källa har mycket lägre kapacitet kommer entropin från RdRand att dominera.

Många kommer med olika förslag att bygga entropikällor med zenerdioder, motkopplade inverterare (på motsvarande sätt som Intel säger att Bull Mountain fungerar). Nackdelen med dessa är att dom kräver extern elektronik samt A/D-omvandlare för att få in entropin i processorn. Att entropikällan är extern kräver också att den är skyddad så den inte går at manipulera.

En intressant grupp av entropikällor är de som försöker använda skillnader i exekveringstid av instruktioner eller andra mätbara effekter från insidan av processorn. Detta tar bort behovet ev externa anslutningar och ger en mer digital miljö som är enklare att observera och kontrollera. Jag har tidigare skrivit om flera av dessa generatorer. Det som är nytt är att det faktiskt ser ut som att flera av dessa generatorer faktiskt ger bra entropi på enkla processorer och för inbyggda system.

För FPGA-baserade system har jag tidigare haft svårt att hitta bra lösningar. Men det finns faktiskt flera publicerade artiklar med exempel på entropikällor och slumptalsgeneratorer i FPGA:er. En av de mer intressanta är ett exjobb som utförts i år på Business Security i Lund. Emma Hilmersson har undersökt flera olika lösningar och skrivit en bra rapport (PDF).

Att testa sin slumptsgenerator är svårt. Väsentligen får man generera en stor mängd värden (En GByte) och sedan släppa lös exempelvis verktyget Dieharder som tar många timmar på sig att analysera värdena på många olika sätt. Sedan får man fundera igenom vad rapporten säger om generatorn.

Att göra dessa tester under drift är svårt. Däremot kan det vara god idé att ha någon slags grundläggande hälsokontroll. Om din generator genererar en miljon nollor på raken, om medelvärdet ligger långt från väntevärdet eller om variansen är mycket mindre än värderymden bör du ta en titt på hälsan hos din generator. Men även för dessa enkla tester krävs rätt mycket värden och fångar inte sekvenser av värden. Därför bör man både under utveckling och under produktens/tjänstens livslängd periodiskt undersöka att generatorn fortfarande fungerar.

En märklig nyhet mitt i alla dessa diskussioner är att NIST har släppt en slumptalstjänst. NISR Randomness Beacon genererar en gång per minut en blobba på 512 bitar med slumptal. Blobban är signerad så att det går att se att den kommer från NIST och blobborna är kopplade till varandra i en hashkedja.

Att döma av beskrivningen är allt kanonsäkert och väl genomtänkt. Men frågan alla ställer sig är varför någon nu skulle använda denna tjänst? Vill du göra din produkt/tjänst och säkerhet beroende av extern entropi över nätet. Entropin är uppenbarligen öppet känd. Och det NIST inte insett är hur mycket organisationen tappat i förtroende. Efter årets stora bråk om SHA-3 och alla avslöjanden är det få som vågar lita på att blobborna faktiskt är genererade på det sätt som NIST säger. Tillit och kontroll. Och just nu vill många få mycket mer kontroll. Om du nu vill använda en tjänst för att få slumptal finns random.org. Nej, jag vet inte riktigt vad man ska med den till heller.