slumptal

Så testar du slumpen

Vid utveckling av kryptografiska produkter eller system är bra slumptal en mycket vital del. Vi har sett många gånger då bristfällig slump leder till katastrofala följder som i fallet med Debians bortoptimerade delar av OpenSSL:

MD_Update(&m,buf,j);
[ .. ]
MD_Update(&m,buf,j); /* purify complains */

Men det finns även andra områden än krypton där bra slump är viktigt. Ta exempelvis TCP ISN som användes av Kevin Mitnick eller nonces och sessionskakor.

Behöver din organisation hjälp med att testa slumptal? Kontakta Triop >

De flesta slumptal som används härstammar från något som heter PRNG (pseudo-random number generator) och betyder att det är pseudo slump som skapas utifrån ett frö (seed). Det finns ett antal olika PRNG algoritmer såsom CryptGenRandom, Blum Blum Shub, Fortuna och Yarrow. Även så brukar man kalla slumptalsalgoritmer som används i krypton för CSPRNG (cryptographically secure pseudo-random number generator)

In the context of a cryptographic system, we have more stringent requirements [than statistical randomness does]. Even if the attacker sees a lot of the random data generated by the PRNG, she should not be able to predict anything about the rest of the output of the PRNG. We call such a PRNG cryptographically strong. […]

Källa: Practical Cryptography

dilbert

Så testar du slumptalsgeneratorn

När du testar slumptal så kan du aldrig vara helt säker på att den alltid kommer att fungera. Det är därför viktigt att genomföra manuella och automatiserade tester löpande. Det är även viktigt att du vet hur dina slumptal kommer att skapas: för är det så att du tar in frövärden/entropi från tangentbord och mus och din kod kommer att köras på en server utan tangentbord och mus.

Ett av de mest kända testbatterierna kallas för Diehard och togs fram runt 1995 av George Marsaglia och senare skapades Dieharder av andra upphovsmän. Även så har NIST ett stort antal resurser såsom dokument och mjukvaror för att testa slumptal, dock så har NIST godkänt slumptalsgeneratorn Dual_EC_DRBG som befaras innehålla en bakdörr (se även extended random). Att köra dessa tester är dock tidsödande men helt klart ett måste.

Om vi skapar en graf så ser vi snabbt att den övre av följande bilder är aningens utstickande (se även view_rng av Joachim Strömbergson):

ej slump
Slumpgenerator 1
slumptal
Slumpgenerator 2

 

entitleOch använder vi sedan verktyget Ent så ser vi att det är uppenbart vilken slumptalsgenerator som troligtvis genererar dålig slump:

Slumpgenerator 1

Entropy = 4.848706 bits per byte.

Optimum compression would reduce the size of this 98794 byte file by 39 percent.

Chi square distribution for 98794 samples is 6163135.43, and randomly would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 66.3816 (127.5 = random).
Monte Carlo value for Pi is 3.998785302 (error 27.29 percent).
Serial correlation coefficient is -0.419748 (totally uncorrelated = 0.0).

Slumpgenerator 2

Entropy = 7.998370 bits per byte.

Optimum compression would reduce the size of this 100000 byte file by 0 percent.

Chi square distribution for 100000 samples is 225.33, and randomly
would exceed this value 90.97 percent of the times.

Arithmetic mean value of data bytes is 127.6192 (127.5 = random).
Monte Carlo value for Pi is 3.148925957 (error 0.23 percent).
Serial correlation coefficient is 0.000984 (totally uncorrelated = 0.0).

De tester som Ent genomför är bra och kan mycket väl fungera som en grundplattform för vidare tester med exempelvis Dieharder.

Vidare läsning:

Informationssäkerheten i Svensk e-legitimation

logotyp-legitimationsnamndeMyndigheten för samhällsskydd och beredskap (MSB) har på uppdrag från tre myndigheter genomfört en säkerhetsanalys av Svensk e-legitimation. De tre myndigheterna är Arbetsförmedlingen, CSN och Försäkringskassan.

Analysen har resulterade i en rapport som innehåller ett antal rekommendationer om vad som behöver göras för att förstärka lösningen Svensk e-legitimation ur ett säkerhetsperspektiv.

Rapporten blev klar den 20 oktober 2014. En fyrsidig sammanställning av analysen publicerades på MSB:s webbplats. Hela rapporten hemligstämplades enligt 18 kap. 8 § och 18 kap. 13 § offentlighets- och sekretesslagen (2009:400).

Men nedan rapport innehåller dock en handlingsplan utifrån resultatet från FRA och MSB:s säkerhetsgranskning.

Sårbarheter i Svensk e-legitimation

Nedan finner du ett utdrag från handlingsplanen gällande kryptoalgoritmer och att gamla och föråldrade algoritmer såsom SHA1 används vilket är häpnadsväckande. Läs gärna igenom hela handlingsplanen nedan och bilda din egen uppfattning, lämna gärna en kommentar också.

”Hög kunskap om kryptoalgoritmer och dess status över tid är en grundförutsättning för att tjänsterna inom samverkan för Svensk e-legitimation ska hålla en hög säkerhet. Det gäller i högsta grad även för underskriftstjänsten som kan avropas och användas i många aktörers tjänster. För att kunna vidmakthålla en hög kunskap krävs regelbunden och återkommande genomgång av området.

Behovet av kryptolösningar finns inom många tjänster i dag. Både sådana tjänster som exponeras över Internet men även interna tjänster. Svagheter i de kryptolösningar som används inom federationens tjänster måste därför identifieras och hanteras löpande. Förändringar i kryptolösningar ställer krav på hantering och eventuell anpassning av de tjänster som använder lösningarna. Alla aktörer som är en del av samverkan i federationen har ansvar för tjänsterna de tillhandahåller.

Nämnden har ett ansvar som federationsoperatör att driva arbetet med att ha rätt säkerhet på de kryptolösningar inklusive algoritmer som används inom federationen och då specifikt för de tjänster som nämnden tillhandahåller. Den genomförda analysen som MSB genomfört har identifierat en kryptoalgoritm (SHA-1) som inte ska användas efter 2013. Underskriftstjänsten som tillhandahålls via ramavtalet ”E-förvaltningsstödjande tjänster 2010” ger inte stöd för användning av SHA-1. Dokumentationen är uppdaterad och de tjänster som finns tillgängliga för avrop ger inte möjlighet för användning av SHA-1. Alla aktörer som ansluter tjänster till Svensk e-legitimation bör se över vilka kryptolösningar som finns i de egna tjänsterna.

Ambitionen för samverkan inom Svensk e-legitimation ska vara att den samlade kunskapen runt kryptolösningar och deras utveckling ska vara hög samt att det ska finnas planer för hur övergången från utgående lösningar ska se ut.”

Handlingsplanen kan laddas hem som PDF här:

Analys av informationssäkerheten i Svensk e-legitimation

Analys av informationssäkerheten i Svensk e-legitimation

NSA avlyssningsoperation IVY BELLS

Operation IVY BELLS var en avlyssningoperation utförd av amerikanska marinen, NSA samt CIA tillsammans. Målet var att avlyssna en undervattenskabel som gick i den ryska sjön Okhotsk till marinbasen i Petropavlovsk. Detta låter kanske som någon nyligen utförd operation men denna operation påbörjades i början av 1970-talet.

Installationen genomfördes på 120 meters djup från ubåten USS Halibut och den specialutvecklade avlyssningsutrustningen var 6 meter lång och vägde 6 ton utvecklad av Bell Labs.

ivy bellsTill amerikanarnas förvåning var nästan all kommunikation okrypterad och flertalet avlyssningstappar installerades från ubåtar som modifierades för syftet.

Varje månad fick även ubåten besöka avlyssningstappen för att byta ut de band som spelade in kommunikationen. Även så konstruerades tappen på ett sådant sätt att den skulle automatiskt släppa om kabeln togs upp för reparation.

Okhotsk

Just denna tapp var borta vid ett av ubåtens besök tio år senare och det visade sig att NSA hade en läcka vid namn Ronald Pelton. Satellitbilder visade då på att ett antal ryska fartyg hade befunnit sig på platsen ovanför tappen.

Under dessa tio år som tappen var installerade gav den amerikanarna stor inblick i den ryska marina kommunikationen.

Tappen återfinnes i dagsläget på ett KGB museum i Moskva och Ronald Pelton som sålde informationen om tappen till ryssarna för 35000$ blev senare avslöjad då hans KGB-kontaktperson Vitaly Yurchenko hoppade av och flyttade till USA (temporärt?).

Att det tog så lång tid att avslöja tappen beror enligt vissa på att den nyttjades till att förse NSA med desinformation.

FBI Wordpress

FBI varnar för allvarlig sårbarhet i WordPress

Amerikanska myndigheten FBI har gått ut och varnat för att den Islamiska staten (ISIS) eller sympatisörer till ISIS använder en ny sårbarhet i WordPress för att genomföra intrång.

Sårbarheten som ISIS använder sig av är relativt ny och återfinnes i pluginet WP Super Cache. Pluginet är mycket populärt och används av över en miljon webbsajter samt har laddats hem över 130 000 gånger bara förra veckan.

Dock så är sårbarheten en XSS där en användare eller administratör av WordPress-sajten besöka en länk som skickas via E-post exempelvis.

WP-Super-Cache-Details-Key

 

Ovan är en skärmdump tagen av Sucuri som påvisar hur $details[ ‘key’ ] används felaktigt utan kontroll för att byta ut information.

Säkerhetstips

Det finns många bra tips för att se till att WordPress är säkert, men främsta tipset är att hålla Er installation uppdaterad. Just denna sårbarhet är åtgärdad i senaste versionen som är 1.4.4. Se även till att aktivt testa säkerheten i WordPress, läs exempelvis här hur du kan göra eller med Detectify.

Källa: FBI

Facebook-lösenord

Så lagrar Facebook lösenord

På en konferens nyligen så avslöjade Facebook hur de lagrar sina lösenord. Eller rättare skrivet hur de hashar sina lösenord.

  1. $cur  = ‘plaintext’
  2. $cur  = md5($cur)
  3. $salt = randbytes(20)
  4. $cur  = hmac_sha1($cur, $salt)
  5. $cur  = cryptoservice::hmac($cur)
  6.         [= hmac_sha256($cur, $secret)]
  7. $cur  = scrypt($cur, $salt)
  8. $cur  = hmac_sha256($cur, $salt)

1. Det första steget är tämligen självförklarande.

2. Gör först en MD5 av lösenordet. Detta ligger troligtvis kvar pga historia då detta troligtvis enbart var det enda steget. Om en användare loggar in och enbart har en md5 så kommer lösenordet att uppdateras med det nya systemet enligt nedan.

3. En salt på 160 bitar är genererad slumpmässigt. För att förhindra kollisioner så bör den vara minst 64 bitar pga antalet användare och övriga bitar är troligtvis för att framtidssäkra.

4. En HMAC med sha1 skapas som sedan skickas in i nästa steg.

5. Detta steg är för att inneha en central kontrolldel och att förhindra offline eller online forceringsattacker mot lösenord.

7-8. scrypt för att försvåra forcering samt skapande av regnbågstabeller. Vi har många gånger tidigare skrivit om scrypt. Samt sista steget är för att göra databasen med lösenord mindre.

Facebook håller även koll på lösenordsdumpar som publiceras på internet och förekommer ditt lösenord i en sådan dump så kommer Facebook att varna dig.

Bedömt så har Facebook lagt mycket kraft bakom lösenordshashningen och det ser mycket bra ut.

Joachim Strömbergson
Joachim Strömbergson

Joachim Strömbergson som är säkerhetsexpert på företaget Assured som också har tittat på Facebooks sätt att lagra lösenord kommenterar enligt följande:

För att sammanfatta min känsla efter 5 sekunder är att man är duktig och använder seed, man har till och med vad som ser ut att vara ytterligare en hemlighet vilket gör det än svårare att försöka göra regnbågsattacker. Vidare använder man dessutom scrypt för att införa work factor som försvårar uttömmande sökning.

Källa på informationen är det som Facebook uppgav vid konferensen Real World Crypt 2015.

Uppdatering: Per Thorsehim tipsar även om att Alec Muffett från Facebook höll en presentation vid konferensen Passwords 2014 i Norge där han berättar mer i detalj:

Facebook lösenord

Stor kryptospecial i Techworld

Senaste numret av papperstidningen TechWorld är nästan helt dedikerad till krypto-området. Och undertecknad finns så klart med några citat såsom:

Allt blir mer komplext när det rör sig om kryptering. Exempelvis blir felsökning krångligare när nätverket är krypterat som standard. Dessutom är kryptoinfrastruktur inget man snyter ur näsan.

Andra som medverkar i artikeln med titel Framtiden är krypterad är:

  • Elise Revell – Kelisec
  • Louise Yngström – professor
  • Mikael Ejner – Datainspektionen
  • Pia Gruvö – MUST
  • Niclas Molander – Cisco
  • Tina Lindgren – Combitech
  • Michael Westlund – Omegapoint

Du kan även köpa tidningen online som PDF för 99 kr här.

Techworld krypto

 

Sectra Tiger godkänt för CONFIDENTIAL

Sectra Tiger/S 7401NATO har nu godkänt Sectras kryptotelefon Tiger/S 7401. för nivå CONFIDENTIAL. Telefonen går att använda över 2G, 3G samt satellitsystemen Iridium, Inmarsat och Thuraya.

Protokoll som telefonen stödjer är blandnannat:

  • SCIP (Secure Communications Interoperability Protocol)
  • SCIP-233 keysets 0x0009 (SCIP-231)
  • 0xF801 (extension of SCIP-231).

Den har 110h standbytid samt går att prata krypterat eller okrypterat under 2.2h. Även så är denna telefon kompatibel med Sectra Tiger/XS som är godkänd upp till NATO SECRET. Även så är Tiger/S 7401 under utvärdering för nivå NATO SECRET (testas av SECAN) och EU SECRET.

Faktorisera 512 bitar RSA SSL/TLS

Nyligen så uppdagades en ny attack mot SSL/TLS vid namn SMACK. Denna attack nyttjar det faktum att många webbsajter i dagsläget erbjuder gamla krypteringsalgoritmer där bl.a. RSA 512 bitar finns med samt en sårbarhet i klienter.

Att faktorisera 512 bitar RSA går relativt snabbt med hjälp av ett kluster hos exempelvis Amazon EC2. Och med hjälp av 75 st servrar hos Amazon tar det cirka 7h och kostar runt 800 SEK. Och verktyget som användes för detta är bl.a. cado-nfs (eller så kan även ggnfs + msieve användas).

Men hur utbrett är problemet eg. med dessa korta nyckellängder på serversidan? Jo, av 14 miljoner sajter som stödjer SSL/TLS så har 36.7% detta problem. Och problemet i detalj består i att om en klient såsom OpenSSL eller Apples SecureTransport får tillbaka ett svar som inkluderar export-grade RSA så kommer dessa klienter att acceptera svaret, även om de ej frågat efter export-grade RSA.

Förfarandet steg för steg:

  1. När klienten skickar sitt Hello-meddelande så frågar den efter standard RSA
  2. Angripare som sitter i mitten (MITM) ändrar detta svar till export RSA
  3. Servern svarar med sin 512-bitars export RSA-nyckel, signerad med sin nyckel för långa livslängder (long term key).
  4. Klienten sväljer detta svar på grund av OpenSSL/SecureTransport-buggen.
  5. Angriparen faktoriserar RSA för att hitta den privata nyckeln
  6. När klienter krypterar ‘pre-master secret’ till servern så kan nu angriparen dekryptera TLS huvudhemlighet (master secret)
  7. Nu kan angriparen se klartext och injicera nytt innehåll

Demonstration av hur attacken kan nyttjas mot NSA (eller rättare skrivet, Akamai):

nsa-fake copy

Tor

Tails 1.3 samt Tor Browser 4.0.4

Det händer en hel del i Tor-världen just nu. Det släpptes just en ny version av Tor Browser men även så släpptes Tails 1.3 igår. Vi försöker sammanfatta nyheterna nedan:

Tails 1.3

Tails har nu förstärkt skyddet i den webbläsare som följer med operativsystemet. Denna härdning använder sig av AppArmor och ser till att webbläsaren enbart får tillgång till vissa valda delar, detta kallas för MAC (mandatory access control).

ElectrumFör att öka stödet gällande kryptovalutor så är nu även Electrum installerat. Electrum är en så kallad wallet eller plånbok där du kan lagra dina Bitcoins säkert(?). För att informationen inte ska försvinna så bör du även nyttja funktionen för persistens.

Även så skeppas en ny proxy med kallad obfs4 som är en vidareutveckling på ScrambleSuite. Denna proxy försvårar för diktaturer eller filtreringsfunktioner såsom DPE (deep-packet-inspection) att detektera att det är just Tor som går på nätverkstrafiken.

Mjukvaran Keyringer finns installerad och denna mjukvara använder sig av GnuPG för att kryptera och distribuera hemligheter:

Keyringer lets you manage and share secrets using GnuPG and Git with custom commands to encrypt, decrypt, recrypt, create key pairs, etc.

Här kan du ladda hem Tails: https://tails.boum.org/download/index.en.html

Tor Browser 4.0.4

Detta är enbart en underhållsuppgradering där åtskilliga komponenter rättas till:

  • Uppdatera Firefox till 31.5.0esr
  • Uppdatera OpenSSL till 1.0.1l
  • Uppdatera NoScript till 2.6.9.15
  • Uppdatera HTTPS-Everywhere till 4.0.3
  • Bugg 14203: Prevent meek from displaying an extra update notification
  • Bug g14849: Remove new NoScript menu option to make permissions permanent
  • Bug g14851: Set NoScript pref to disable permanent permissions

Och Tor Browser Bundle laddar du hem här:

PGP är dött

PGPPGP (och numera GPG) är ett av det bästa som hänt modern krypterad kommunikation, men tyvärr är GPG svårt att använda och det är lätt att det blir fel. Det behövs ett omtag när det gäller GPG och vi väntar bara på att bägaren ska rinna över innan det händer.

För sanningen är, att GPG är tillräckligt bra. Visst behövs det göras en hel del när det gäller UX, metadata och forward secrecy men så länge det bara fungerar så behövs det inte åtgärdas.

Men hur kan den stora massan börja att använda krypterad E-post? Även om TLS på E-post (STARTTLS) blir mer utbrett så är detta ej ett komplett skydd.

Är det så att det eventuellt behövs en stor kampanj på Kickstarter för att någon nytt system ska bli det nästa GPG? För fortsättningsvis kommer vi att använda GPG och vi kommer att göra fel och nycklar kommer att bli röjda för vem kommer ihåg när Aftonbladet publicerade sin privata nyckel?

Buggar blir fixade och GnuPG har fått en större budget nuförtiden, så det går sakta men säkert åt rätt håll med intiativ såsom Google End-to-end.

”Key distribution is the hardest problem in end-to-end encryption”

Google

Läs även kloka ord av Moxie samt Whiteout