Get in touch!

Use the form on the right to contact us.

We answer emails as soon as we can. See the contact page for more information.

           

123 Street Avenue, City Town, 99999

(123) 555-6789

[email protected]

 

You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

Blog

Training to become an Assured Ninja

Johan Rydberg Möller

Assured runs something we like to call the ”Assured Expert Consultant Program”. It’s a training program for new-hires whose interest and passion for security is more important than their actual time and experience in the field.

Over six months, the new consultant will endure both internal and external courses, focused on honing their expertise in IT-Security. Internal training is held by other Assured consultants where they speak about their specific field within IT-security. External courses could be anything of the consultants’ choice as long as it’s connected to security and the specific area the consultant wishes to improve in. The training hopefully results in a confident Assured consultant and security expert who will be able to deliver quality work on any assignment (s)he’ll take on!


My name is Benjamin and I was the first guinea pig in the Assured expert consultant program which started in April of 2017. My first week at Assured began by setting a rough plan for my program. One day per week was set aside for internal training held by Assured consultants, the rest of the time was open for me to work together with my technical mentor Jesper and for external training.

As I mentioned, the internal training was scheduled for once a week and held by an Assured consultant. My colleagues spoke about a subject within their area of expertise like PKI, OpenSAMM, Security Operations and Network and web penetration testing, to name a few. This wasn’t only educational in the sense of me acquiring knowledge, I also got a good understanding of which part of the IT-security area my colleagues are specialized in, and they got a better understanding of my base knowledge within the different fields. 

All assignments I worked at were led by Jesper, and he had all the responsibility to deliver quality work to the customer. That made me feel more relaxed during my first months as I wasn’t under as much pressure, but all the motivation to do quality work. During every assignment, we discussed the goal we had and how to get there. I got to be involved every step of the way and in every decision we had to make. During a few assignments Jesper only stood by as a mentor and I did close to all the work required. I quickly learned how Assured was working with customers and how to produce good and manageable results which I as an Assured consultant can stand for.

A few assignments however were very complex and had to be delivered after a short period of time. This made it difficult for Jesper to mentor me properly during that period. That’s when online training comes in handy. Doing CTFs, wargames and research developed my technical knowledge and were a lot of fun at the same time!

During my last weeks in the program I took Offensive Security’s Cracking the Perimeter course. It was a very difficult but educational course as it touched an area in which I had next to zero experience, reverse engineering.

To sum up the past five months at Assureds expert consultant program I’ve increased my security knowledge exponentially, mainly within network security and penetration testing. I’ve also gained a lot of experience as a consultant in how to engage customers and how to provide them with quality results to help improve security in the world of IT. 

If you’re interested in embarking on the same journey I’ve been on over the last months, shoot an email over to [email protected] and we’ll talk! If you want to reach out to me directly I'm on Twitter @bewniac.

Säkerhet för Internet of Things - Inget är nytt, allt har ändrats

Joachim Strömbergson

Inbyggda system och Internet of Things
I grund och botten ser jag inte att Internet of Things är någonting fundamentalt
nytt. Det är samma typer av inbyggda system som integrerats i produkter - i saker. I takt med Moores lag har allt mer beräkningskraft och därmed digitala funktioner, dvs informations och informationsbearbetning kunnat läggas till fysiska objekt och göra dom smartare.

För att illustrera har Moores lag gjort att processorprestandan hos den mycket dyra arbetsstation från Sun jag arbetade på i början av 1990-talet i dag finns i en glödlampa som kan byta ljusets färg på kommando.

Ett inbyggt system är helt enkelt en dator som lever ett långt, enahanda, ensamt och otacksamt liv.

De huvudsakliga parametrarna vid design av ett inbyggt system är:

  1. Kostnad
  2. Funktion och eventuell realtidsprestanda
  3. Fysisk storlek
  4. Kostnad
  5. Livslängd
  6. Servicebarhet
  7. Effektförbrukning och miljökrav
  8. Kostnad

Internet of Things (IoT) innebär att det inbyggda systemet, den övergivna datorn får möjlighet att kommunicera med omvärlden. Frågan är bara med vem och om vad?

Det inbyggda systemet tillförs helt enkelt funktionskravet att kommunicera med sin omvärld med IP-paket. Det är den enda skillnaden. I övrigt är det samma krav. Och utvecklingen av IoT-system sker på samma sätt, med samma villkör och i allt väsentligt av samma personer som för inbyggda system.

Kommunikationsfunktionaliteten är i allt väsentligt samma nätverksteknik som vanliga datorer använder för att kommunicera. Men tack vare den tekniska utvecklingen har priserna för att lägga till nätverkfunktionalitet till inbyggda system kommit ned i prisnivåer som är rimliga för många produkter. Även minskning av fysisk storlek och kompakta byggsätt gör att det går att integrera antenner och andra fysiska kommunikationskomponenter i många produkter.

Samtidigt innebär nätverksfunktionalitet, och då speciellt funktionalitet för att kommunicera på Internet en fundamental förändring av systemets gräns. Plötsligt kan glödlampan, tandborsten, vattenpumpen, gasolgrillen, hemlarmet, kattluckan, badrumsfläkten, glassmaskinen etc börja prata med andra enheter över hela jorden. Därmed kan systemet påverka och påverkas inte bara av sin lokala miljö.

Detta har lett till att IoT-enheter snabbt blivit ett potentiellt säkerhetsproblem. Anders Thoresson har skrivit en artikel om detta i NyTeknik. I artikeln är jag intervjuad och artikeln har lett till flera diskussioner. Den här texten är ett slags försök att förklara hur jag tänker.


Säkerhet för IoT
De grundläggande säkerhetsproblemen som finns för IoT skiljer inte från andra kommunicerande system. Vi behöver samma typer av säkerhet: Integritet, äkthetskontroll och identifiering och konfidentialitet. Det sista, konfidentialitet, att skydda information från att läsas av tredje part är det man traditionellt löser med kryptering. Det är också ofta det minst viktiga för IoT. Temperaturen i kylskåpet eller varvtalet på en fläkt är inte kritiskt om någon får reda på. Men det är viktigt att veta att informationen kommer från rätt enhet, att värdet inte har förvanskats eller att det skapats på kommando från en part som har rätt att skicka kommandon till systemet.

För normala datorsystem löser vi dessa problem med en verktygslåda av algoritmer, konstruktioner baserade på algoritmerna och protokoll som använder konstruktionerna för att på ett definierat sätt lösa olika relationer och utbyten mellan parter. Algoritmer som AES, SHA-256, RSA, Elliptic Curve. Konstruktioner som HMAC, GCM, Bcrypt. Protokoll som TLS.

En vanlig uppfattning är att dessa algoritmer, konstruktioner är för tunga för IoT-applikationer. Det pågår därför massor med iofs spännande forskning på lättviktskrypton och specifika protokoll för IoT.

Jag vill dock hävda att uppfattningen ofta inte stämmer. För de allra flesta IoT-applikationer har vi redan i dag tillräckligt kompakta implementationer av befintliga algoritmer och protokoll för att fungera kostnads- och prestandamässigt. Och detta kommer att förbättras över tiden i takt med allmänna teknikutvecklingen (1). Mot detta ska ställas att använda en mycket mer obeprövad lösning som ingen känner till. Det ger osäkerheter och försvårar integration och interoperabilitet. Jag skulle aldrig någonsin rekommendera det av NSA för IoT utvecklade blockkryptot SIMON framför AES.
 

Rent krasst kostar säkerhetsfunktionaliteten i första hand minne - utrymme för kod i Flash sam arbetsminne i RAM. Samtidigt är mängde minne i en krets den resurs som skalar snabbast med nya kretsprocesser. Prestandamässigt kan initiering av session vara tidskritiskt, men annars har de flesta IoT-applikationer tillräckligt med dödtid att det finns gott om cykler att utföra nödvändiga beräkningar (2).

Vi har redan i dag ett antal lösningar för att utbyta hemligheter, kommunicera säkert MbedTLS, Nettle, TweetNaCl med algoritmer och protokoll (ex DTLS, 6LowPAN, CoAP) har vi som jag ser det en rejält fylld verktygslåda Med TLS 1.3 som kommer senare i år får vi även in fler kurvor och kryptmoder (ex OCB) som lämpar sig väl för IoT-applikationer.

Tittar man på utbudet på MCU:er är det faktiskt så att väldigt många kommer i varianter som inkluderar i alla fall en AES-kärna för ingen eller minimal skillnad i pris. Har vi AES kan vi bygga ett antal konstruktioner för att lösa konfidentialitet, integritet och autentisering.

Enligt min mening är det inte inte kryptomekanismer eller kryptoptokoll som ger IoT säkerhetsproblem. Det är istället i enklare, mycket mer triviala saker.

Typiskt använder man standardnycklar i alla individer av en produkt, vilket innebär att faller en nyckel faller säkerheten hos alla individer. Produkter har ofta även standardanvändare och lösenord för administration. Dess identiteter och lösenord ändras inte vid installation.

Ett bra exempel på hur illa det kan vara är protokollet MQTT. Protokollet är ett enkelt meddelandeprotokoll mellan enheter som kommunicerar asynkront via en mellanhand, en broker. MQTT har fått stor spridning för IoT. Tyvärr stödjer MQTT dåligt vettiga säkerhetsmekanismer, och de som finns används sällan. Vilket säkerhetsexperten Lucas Lundgren upptäckte.


Det jag ser är specifikt problematiskt för IoT-prylar är

  • Koordinering av många miljoner enheter samtidigt på ett effektivt sätt. Samtidigt visar DDoS-attackerna med kameror att det går att lösa.
     
  • Säker uppdatering av inbyggd programvara (Firmware - FW). De allra flesta mekanismer för uppdatering jag sett brister alla på olika sätt. Den bästa jag sett så här långt är den Apple använder för sina iOS-enheter.  Med Internet of Things vill man ofta göra uppdateringen på distans (Firmware Over The Air - FOTA). Samtidigt är det stora problemet för inbyggda system inte att göra säker uppdatering. Problemet är istället att FW inte uppdateras så länge inte systemets grundfunktion slagits ut. Detta trots att det finns kända problem och sårbarheter.
     
  • Verifiering av tillitsankare. Ett tillitsankare (Root of Trust) är basen för att en part kan styrka motpartens äkthet utan att man på förhand har utväxlat en för parterna gemensam hemlighet. Ofta löser man detta genom olika typer av parningsförfarande i samband med installation.
     
  • Livslängder och kärlek. För ett system som lever 10, 20, 30 år kommer antaganden om exempelvis protokoll och algoritmers motståndskraft mot attacker att ändras. Systemen kommer dock sällan att uppdateras som reaktion på dessa förändrade fundamental.
     
  • Felsökning och underhåll. Att kombinera möjlighet att observera och modifiera interna tillstånd utan att rubba den säkerhetsmässiga integriteten.

Säkerhetsläget för vanliga IT-system är inte perfekt. Långt därifrån. Men det borde inte hindra oss från att applicera tillkämpad kunskap från dessa system för att säkra upp IoT. Att inte (ännu en gång) upprepa samma misstag. Över huvud taget upplever jag att det finns ett kompetensbehov bland utvecklare av inbyggda system och Internet of Things. Att få hjälp att förstå hur säkerhet fungerar, hur man identifierar vilken säkerhet systemet man utvecklar faktiskt behöver.

Säkerhet kostar, både i ökad utvecklingskostnad och i produktens kostnad över dess livscykel. Därför borde inte lägga pengar på att utveckla och använda säkerhetslösningar som ger fel säkerhet för systemet och applikationen. Att inte använda algoritmer som vi redan i dag vet inte längre ger säkerhet, exempelvis hasfunktionen MD5. Och inte utveckla egna osäkra säkerhetslösningar och protokoll. Istället använda beprövade mekanismer som finns och vi litar på, integrera befintliga, bra implementationer och lägga tid och pengar på att verifiera att säkerhetsmekanismerna fungerar i systemet. Inte minst att verifiera att systemet beter sig på förväntat sätt när säkerheten fallerar.

Väl utvecklade, installerade och korrekt använda IoT-lösningar borde kunna ha samma nivå på säkerhet som väl fungerande generella IT-lösningar.

Joachim Strömbergson


Fotnötter
(1) Jag är medveten om att Moores lag för high end-processorer i stort sett stannat av. Men processorer i IoT-tillämpningar tillverkas fortfarande i ganska gamla processer ex 90 nm. Det är långt kvar ned till 14, 10 nm som är framkant för Moores lag i dag.

(2)  I en del tillämpningar finns det mer eller mindre strikta krav på responstid (realtidssystem). Här underlättar hårdvarustöd för implementationer, ex att kryptot AES finns som hårdvarublock i processorn.

Nytt sätt att hitta kolliderande nycklar i strömkryptot RC4

Joachim Strömbergson

Strömkryptot RC4 har varit rejält trasigt i flera år nu. Trots det visar SSL Pulse att nästan 40% av alla webbplatser som använder HTTPS fortfarande stödjer kryptosviter med RC4.

Forskarna har dock inte slutat sparka på RC4 och för någon dag sedan dök det upp en artikel på IACR med nya resultat för RC4 som visar att det inte bara finns fler kolliderande nycklar, utan även beskriver en algoritm för att mer effektivt hitta kolliderande nycklar.

Så vad är då kolliderande nycklar? Jo, helt enkelt att två (eller fler) kryptonycklar som är olika initierar RC4 till samma tillstånd och därmed får RC4 att generera samma sekvens. En sådan kollision innebär att även om en nyckel skapats med omsorg (bra slump) är den mindre unik och därmed mindre säker än man skulle kunnat förmoda.

Simon Josefsson postade 2013 en artikel på IACR som visade att två nycklar som kunde vara av olika längd, men som bestod av samma upprepade mönster kolliderade:

 Key k3 = [0x01,0x02,0x03,0x04] (32 bit)
 Key k4 = [0x01,0x02,0x03,0x04,0x01,0x02,0x03,0x04] (64 bit)
 Generated keystream: 0x1c,0xea,0x91,0x61,0xee,0xbc,...

Men dessa nycklar hade alltså repeterande mönster. Det den nya artikeln visar är att ex följande nycklar ger upphov till samma sekvens:

1st pair: 1C 50 22 84 5B 74 EC B6 62 F5 95 7E 04 5F 5A 08 4A 6B C7 2C (2D) 02 95,
2nd pair: 58 76 1D 95 DC F6 E8 13 00 47 4E D2 41 C1 01 4A 57 7D C7 BD (BE) 02 68,
3rd pair: 8F E2 82 5D 51 74 8A BF 28 1D E1 23 0A 8E 3C FE 98 5C C7 21 (22) 02 6A

Att hitta en nyckel med den nya algoritmen går dessutom relativt snabbt. Intressant nog går det fortare att hitta kollisioner för längre nycklar än kortare - men det finns helt enkelt fler nycklar som kolliderar ju längre nyckeln är.
 

Ännu en spik i kistan för RC4 helt enkelt. Och artikeln visar om inte annat det som Bruce Schneier påpekat i många år - att attacker inte blir sämre, utan blir bättre och bättre med tiden. Nyfikna personer kan inte låta bli att peta i såret. Vill du slippa mer obehagligheter och inte redan gjort det, fimpa RC4.

TLS fuzzers and extending tlsfuzzer

Peter Magnusson

TLS stacks have had their fare share of problems in the last few years, from simple failures such as Heartbleed and gotofail to cryptographic flaws such as the ever re-emerging problems with mac-then-encrypt cipher suites.

To enable developers and security researchers to test and detect protocol flaws, a number of fuzzing & testing suites have emerged; tlsfuzzer (python), tls-attacker (java), scapy-ssl_tls (python), flextls (python).

What these fuzzers allow you to do is to create custom error modes in the protocol handling, creating a server or client that misbehaves, and then add code to detect if the other side is responding in an incorrect manner.

Assured Ninja Peter Magnusson boldly set out to test if AES_GCM suites' authentication tag actually is being checked by a target platform, and was surprised to realise the first fuzzers I looked at haven't implemented it. As a java / C developer, the obvious choice would seem to be to modify tls-attacker, but I figured "learning" Python was a better choice as a personal learning experience, and I imagined a scripting language such as Python is far more popular among security researchers. I had a very brief look at scapy-ssl_tls but gave up, and then re-focused on Hubert Kario's tlsfuzzer.

tlsfuzzer overview:

  • An exceptionally easy to understand fuzzing framework, with a clear directory structure attacks and proof of concepts under /scripts, library code base under /tlsfuzzer, and unit-tests under /tests.
  • Mostly Python-2.7 compatible, but the unit tests require Python-3.
  • The source code is quite easy to comprehend (considering how complex tasks it carries out), so extending it is not unnecessarily complicated.
  • Logically split between tlsfuzzer (the fuzzing framework) and tlslite-ng (the tls stack modified by the fuzzer) which makes the source code easier to comprehend.

Patching tlsfuzzer

Basically I did the awesome thing and fiddled around in the fuzz-mac scripts, made an option for fuzzing AEAD messages. The hardest thing was to understand tlslite-ng structures, but overall it was pretty straight forward, even if I admittedly barely understood my patch and Python :) Created a github pull request (tlsfuzzer #40). Then there was couple of rounds with feedback from Kario, and the patch was significantly refined and generalised to allow fuzzing any ciphertext from any suite. Additionally I created a unit test, which for some silly reasons were way harder than actually creating the new feature, and actually made me understand tlslite-ng and tlsfuzzer quite a bit more!

Final words

So, making custom tests for TLS stacks is getting easier. From my experience tlsfuzzer seems an excellent platform to choose for development, due to being actively developed, having very simple structure to projects and easy to read source code. And submitting patches to github was great, getting useful feedback.

RFC 7905 - Nya kryptosviter för TLS och DTLS

Joachim Strömbergson

I natt blev en ny RFC publicerad av IETF som standard. RFC 7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) beskriver en ny uppsättning kryptosviter för TLS. Kryptosviterna bygger på strömkryptot ChaCha20 och ger så kallat AEAD-skydd, dvs autenticerad kryptering vilket ger både konfidentialitet och integritetsskydd samt stöd för metadata som också autenticeras. Och viktigt nog, autenticeringen sker på det krypterade datat (Encrypt then Autenticate - EtA). De specificerade kryptosviterna finns även anpassade för DTLS.

Publiceringen innebär slutet på det arbete Simon Josefsson, Nikos Mavrogiannopoulos, jag (Joachim Strömbergson) samt Adam Langley och Wan-Teh Chang startade för flera år sedan.

Grunden för mitt engagenang startade med att strömkryptot RC4 visade sig vara helt trasigt och inte längre var lämpligt för bland annat TLS. Konsekvensen var att det enda symmetriska krypto som fanns kvar i TLS var AES. AES är ett mycket bra krypto. Men det började bli en rejäl monokultur runt AES, om AES skulle visa sig vara svagt skulle konsekvenserna bli stora. Även om någon av andra skäl vill använda något annat symmetriskt krypto i TLS blir det problem. Ett konkret skäl att inte vilja köra AES är att få bra prestanda, speciellt på mindre processorer som inte har hårdvarustöd för AES. RC4 i jämförelse är mycket snabbare.

Samtidigt hade EU-projektet ECRYPT avslutat sitt eSTREAM-projekt där ett stort arbete lagts ned på att få fram nya, moderna strömkrypton. Krypton som både ger bra prestanda på stora och små processorer och med bra säkerhetsmarginal.

Vi började därför titta på att specificera kryptosviter för TLS som istället använde något av strömkryptona från eSTREAM. Av flera skäl (prestanda, skalbar säkerhet, bra licenskrav, väl specad beskrivning) valde vi Salsa20. Samtidigt blev det tydligt att vi även behövde en autenticeringsfunktion. Om jag minns rätt var det Nikos som presenterade och argumenterade för att använda Poly1305. Då byggde dock funktionen på AES som intern nyckelderiveringsfunktion (Key Derivation Function - KDF).

Så småningom visade det sig att det pågick ett närmast identiskt, långt gånget arbete med att ta fram nya kryptosviter av Adam Langley och Wan-Teh Chang. Ansträngningarna kombinerades och så småningom ändrades även kryptot till versionen av Salsa20 som kallas ChaCha20. ChaCha20 ersatte även AES som KDF i Poly1305.

De nya kryptosviterna finns för TLS 1.2 och Google har sedan tidigare implementerat kryptosviterna i Chrome. Men kryptosviterna är speciellt viktiga för nästa version av TLS, TLS 1.3 som förhoppningsvis kommer att standardiseras i år eller i början av 2017. ChaCha20-Poly1305 finns även implementerat i flera kryptobibliotek exempelvis Nettle.

För den som vill veta mer om implementationen av ChaCha20 och Poly1305 finns en mycket bra informations-RFC tidigare publicerad av Adam Langley och Yoav Nir. I RFC 7539, ChaCha20 and Poly1305 for IETF Protocols finns inte bara detaljerad information om ChaCha10 och Poly1305 med ChaCha20 utan det finns även testvektorer för alla delar. RFCn inkluderar även lite prestandainformation:

Prestandasiffror från RFC 7539. Notera att för x86-processorer utan AES-NI-instruktioner kommer ChaCha20-Poly1305 att ge bättre prestanda.

Prestandasiffror från RFC 7539. Notera att för x86-processorer utan AES-NI-instruktioner kommer ChaCha20-Poly1305 att ge bättre prestanda.

Om man vill göra en hårdvaruimplementation har jag sedan tidigare utvecklat en öppen implementation av ChaCha20. Att bygga Poly1305 och en core som tillhandahåller hela ChaCha20-Poly1305-funktionaliteten utifrån ChaCha20 borde vara ett förhållandevis enkelt arbete. Om sommaren blir svenskt regnig kan det mycket väl finnas en sådan core färdig till hösten.

Writeup for the SecurityFest 2016 CTF challenge SHAlien

Joachim Strömbergson

The SecurityFest 2016 contained a great CTF with a wide range of challenges. This is a short writeup for how to solve the challenge SHAlien.

The challenge file is called shalien.tar.gz. We use tar -xvzf shalien.tar.gz to untar and gunzip the file. We get a directiory called sha(lien). The dir contains the files:

01765ddfd925d70d41d53cabdba5f2588e678e534ef5d8840a813bc58d33198039006ce6395c6b95747a2e05d21ff3a47389638ba9405fd11ab1b0857f56426f
030514d80869744a4e2f60d2fd37d6081f5ed01a
10159baf262b43a92d95db59dae1f72c645127301661e0a3ce4e38b295a97c58
262bdb6eb4a95ab843ed26d46ccf77f2b26db3a8e16f207b2275e3d0a55eb724d5408b08287d2e3a7b7e365959ff34d47a8a1f3e17da8cf2fe9bf3d0fd8d5308
3c49cb3157ec3feaf0f97156e5c11dca0ffd6481c97bb1a5dffaa14f
4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865
5791151e6d3ca20a222466229f7aa5869cd67fa92cb20a81efe28d90b77e40e89bc10f04439c1c69100b65fd4d0d7ff166001db0f459e26b4b5369ba0870909f
7de1555df0c2700329e815b93b32c571c3ea54dc967b89e81ab73b9972b72d1d
7f04f368ab5b53d568c1590932a5ceebec89b14fcb03bf7f46197078
871b84bf3657493b719b29f68a805ad322f7508dff7008e80485d21e
a3db5c13ff90a36963278c6a39e4ee3c22e2a436
aa67a169b0bba217aa0aa88a65346920c84c42447c36ba5f7ea65f422c1fe5d8
aee69d4b47bcb9b1a711d622baab1fabaa53987ac57037906b7a5d5d
ccf271b7830882da1791852baeca1737fcbe4b90

Weird files with hexadecimal file names of a few different lengths. Running the file tool on the files reveals that all these are PNG image data, 100 x 100, 8-bit/color RGBA, non-interlaced files. We add the png file type to all files and get the following images:

The files viewed as images

The files viewed as images

Hmmm. that == image and the other ones sure looks like a bas64 encoding. But what about the order of the files?

Considering the names of the files and the challange, we seem to have names that corresponds to SHA digests with lenghts of 160, 224, 256 and 512 bits. Testing with different order strings and the different different NIST FIPS 180-4 (SHA) algorithms implemented in the tool shasum withwe find the following relation between order number and file names:

echo "1" | shasum -a 256, image = "c2"
4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865.png
echo "2" | shasum -a 224, image = "9f"
7f04f368ab5b53d568c1590932a5ceebec89b14fcb03bf7f46197078.png
echo "3" | shasum -a 1, image = "eW"
a3db5c13ff90a36963278c6a39e4ee3c22e2a436.png
echo "4" | shasum -a 256, image = "91"
7de1555df0c2700329e815b93b32c571c3ea54dc967b89e81ab73b9972b72d1d.png
echo "5" | shasum -a 224, image = "X2"
3c49cb3157ec3feaf0f97156e5c11dca0ffd6481c97bb1a5dffaa14f.png
echo "6" | shasum -a 1, image = "Nh"
ccf271b7830882da1791852baeca1737fcbe4b90.png
echo "7" | shasum -a 256, image = "bl"
10159baf262b43a92d95db59dae1f72c645127301661e0a3ce4e38b295a97c58.png
echo "8" | shasum -a 256, image = "9y"
aa67a169b0bba217aa0aa88a65346920c84c42447c36ba5f7ea65f422c1fe5d8.png
echo "9" | shasum -a 224, = "ZW"
871b84bf3657493b719b29f68a805ad322f7508dff7008e80485d21e.png
echo "10" | shasum -a 224, image = "Fk"
aee69d4b47bcb9b1a711d622baab1fabaa53987ac57037906b7a5d5d.png
echo "11" | shasum -a 512, image = "X2"
262bdb6eb4a95ab843ed26d46ccf77f2b26db3a8e16f207b2275e3d0a55eb724d5408b08287d2e3a7b7e365959ff34d47a8a1f3e17da8cf2fe9bf3d0fd8d5308.png
echo "12" | shasum -a 512, image = "1l"
5791151e6d3ca20a222466229f7aa5869cd67fa92cb20a81efe28d90b77e40e89bc10f04439c1c69100b65fd4d0d7ff166001db0f459e26b4b5369ba0870909f.png
echo "13" | shasum -a 512, image = "Cg"
01765ddfd925d70d41d53cabdba5f2588e678e534ef5d8840a813bc58d33198039006ce6395c6b95747a2e05d21ff3a47389638ba9405fd11ab1b0857f56426f.png
echo "14" | shasum -a 1, image = "=="
030514d80869744a4e2f60d2fd37d6081f5ed01a.png

Collecting the base64 code we get: c29feW91X2Nhbl9yZWFkX21lCg==
Decoding it we get: so_you_can_read_me\n. Removing the newline we have the flag.
 

 

Snart dags för Security Fest 2016!

Joachim Strömbergson

Om bara två dagar är det dags för säkerhetskonferensen Security Fest 2016 i Göteborg.

Bland skaparna och arrangörerna av konferensen återfinns Assureds Jesper och Johan. Assured är även stolt sponsor av konferensen.

Assured kommer naturligtvis att vara där. Kom till vårt bord och var med och tävla om fina priser. Vi har klibbor också. Vi ses på torsdag!
 

Uppdaterad hårdvaruimplementation av SipHash

Joachim Strömbergson

SipHash är en så kallad pseudoslumptalsfunktion (psudo random function - PRF), det vill säga en nyckelberoende funktion som mappar indata till ett utdata på ett slumpmässigt sätt. Typiska exempel på användning av PRF:er är för att generera autenticeringskoder för meddelanden.

Det som gör SipHash intressant är att den är mycket snabb, ställer låga krav på systemmiljön (processorns operationer och operander) och att den är säker. SipHash är snabbare än andra PRF:er och till och med snabbare än många icke-säkra hashfunktioner. Sedan Aumasson och Bernstein introducerade SipHash har den bland annat blivit den underliggande hashfunktionen i ett stort antal programspråk (ex Perl, Python, Ruby, Rust), verktyg som OpenDNS och operativsystem so OpenBSD, FreeBSD.

För ett par år sedan implementerade jag hashfunktionen SipHash i hårdvara. Implementationen var relativt simpel, men visade att SipHash i hårdvara blir kompakt och ger hög prestanda, båda viktiga egenskaper för inbyggda system.

En nackdel med den gamla versionen av SipHash var att resultatet vara var 64 bitar stort. Det ger en väl låg säkerhet mot gissningsattacker. Aumasson och Bernstein löste detta genom att utöka SipHash till 128 bitar. Men tyvärr har jag inte uppdaterat min implementation.

Men nu finns en uppdaterad hårdvaruimplementation av SipHash som stödjer både 64- och 128-bitarsh hashresultat. Samtidigt har jag städat, snyggat till, förbättrat implementationen. Inte minst har det tillkommit en bra Pythonmodell som stödjer båda storlekarna av hashresultat och kör ett antal testvektorer. Även testbänkarna för hårdvaruimplementationens olika delar kör nu bra tester och är dessutom självtestande.

Implementationsmässigt kräver SipHash färre resurser (logik och register) än MD5 i en Altera Cyclone 4E, och går att klocka dubbelt så fort. Samtidigt tar det SipHash ett fåta cykler att genererar hashresultatet i jämförelse för typiskt 64 cykler för MD5.

Samtidigt ska det medges att jämförelsen med MD5 haltar lite. SipHash är inte en kryptografiskt säker hashfunktion utan en PRF. Men å andra sidan är MD5 inte heller en kryptografiskt säker hashfunktion och ska INTE användas som det. Men en gång när MD5 utvecklades var syftet att vara kryptografiskt säker.

Men om du bygger en FPGA och letar efter en snabb, kompakt hashfunktion, eller om du behöver integritetsskydda data med en nyckelberoende meddelandeäkthetskod finns nu SipHash med upp till 128 bitars kod.

Min förhoppning är att min implementation är enkel att integrera. Om den inte är det, hör av dig!

(Joachim Strömbergson)

Workshop om programuppdateringar i IoT-enheter

Joachim Strömbergson

En av de riktigt kritiska besluten vid design av ett inbyggt system är huruvida programvaran (ofta kallad firmware) ska kunna uppdateras efter att saken datorn/processorn sitter i har producerats och levererats. Och om det ska kunna ske, på vilket sätt det ska ske.

Ska uppdateringar kunna ske på avstånd, eller måste en tekniker koppla upp sig till enheten med en sladd lokalt? Ska det gå att gå tillbaka till en gammal version av programvaran om den nya visar sig inte fungera? Detta är exempel på frågor som för med sig stora säkerhetsmässiga aspekter. Svaren på dessa frågor kan även driva komponentkostnader, genom att exempelvis ställa krav på större mängd minne, stöd för olika algoritmer.

Livslängden på de saker ett inbyggt system sitter i kan variera högst väsentligt. Men att det i dag skruvas upp saker som förväntas användas under 30 år är inte ovanligt. På den tiden hinner det ske stora förändringar i hur saker kommunicerar, vilka datorresurser som kan finnas etc. Att kunna uppdatera systemet för att svara upp mot förändringar blir viktigt.

Speciellt för Internet of Things (IoT) blir detta väldigt tydligt. När vi pratar om IoT handlar det ofta om ytterst små, kostnadspressade system med relativt lång förväntad livstid avsedda att kommunicera över publikt Internet. IoT närmast kräver att systemen kan uppdateras för att anpassas till förändrad omvärld och hotbild.

Tyvärr ser jag i min roll som säkerhetsexpert ofta exempel på uppdateringsmekanismer som ger inget eller verkningslöst skydd (vilket enbart driver kostnad i onödan), eller mekanismer med grava svagheter. Inte sällan är dessa uppdateringsmekanismer skapade av konstruktören av det inbyggda systemet. Men även färdiga lösningar från leverantörer av processorer för inbyggda system (Microcontrollers - MCU) eller moduler är tyvärr inte sällan utan mer eller mindre allvarliga brister. I de fallen riskerar dessutom flera olika system och olika företags produkter att bli sårbara.

Med denna problemsituation var det därför glädjande att se ett intressant initiativ för att förbättra situationen. Internet of Things Software Update Workshop (IoTSU) är en workshop anordnad av IETF och IPSO. Syftet är att diskutera dagens situation samt standardisering av protokoll, dataformat och underliggande mekanismer för att ta skapa bra lösningar för programuppdateringsmekanismer. Workshopen går den 13-14 juni Dublin. Fokusområden för workshopen är:

  • Protocol mechanisms for distributing software updates.
  • Securing software updates.
  • Meta-data about software / firmware packages.
  • Implications of operating system and hardware design on the software update mechanisms.
  • Installation of software updates (in context of software and hardware security of IoT devices).
  • Privacy implications of software update mechanisms.
  • Seeking input on experience and state-of-the-art.
  • Implications of device ownership and control for software updat
 

Jag hoppas kunna vara där, men kommer oavsett att bevaka de diskussioner som garanterat kommer att skapas på ett antal maillistor.
 

Nya elliptiska kurvor för att säkra Internet publicerade

Joachim Strömbergson

I förra veckan publicerade IETF dokumentet RFC 7748 - Elliptic Curves for Security.

Denna RFC specificerar två elliptiska kurvor avsedda att exempelvis implementera nyckelutbyten (ECDHE), signering (https://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman) och kryptering i olika Internetorotokoll. Exempelvis kommer kurvorna i och med den här publiceringen att finnas med i de kryptosviter som tas fram för kommande stora uppdatering av standarden TLS, vilken förhoppningsvis publiceras senare i år. Men även framtida certifikat kommer nu förhoppningsvis att i större utsträckning använda EC-nycklar.

Vad är då poängen med de nya kurvorna, vi har ju redan ett antal kurvor publicerade av olika organisationer? Dedt finns ett par bra skäl till varför de nya kurvorna är intressanta.

Den i dag vanligaste kurvan är P256 som är specificerad av NIST, mer precist är det NSA som skapat kurvan som NIST sedan specificerat. Hur NSA kom fram till de parametrar man valt för att skapa den specifika P256 vet vi inte. NSA anger att det ger en prestandamässigt effektiv kurva. P256 är dock inte speciellt snabb. Speciellt inte i jämförelse med dagens kurvor, exempelvis de som är specificerade i den nya RFC:n. P256 är dessutom svår att implementera utan att koden innehåller villkorade operationer som ger upphov till variabel exekveringstid. Detta beteende riskerar att läcka känslig information (så kallat sidoläckage). Kryptologerna Daniel J Bernstein och Tanja Lange har skrivit en bra artikel som bland annat beskriver svårigheten med att implementera P256 på ett säkert sätt.

Andra , exempelvis Goldilocks-kurvorna specificerade av tyska BSI, lider av liknande problem med spårbarhet och säkra implementationer som P256. Över huvud taget har det öppna säkerhetssamfundet inom exempelvis IETF blivit mycket mer känslig för hur standarder utvecklas, att hänsyn till implementationer tas och vad som ligger till grund för designbeslut. Trots detta har framtagningen av de nya kurvorna i RFC 7748 varit allt annat än okontroversiellt. Diskussionerna har varit många, heta och långa. Det har även förekommit anklagelser av förhalning och sabotage. Ett direkt exempel är när Microsoft introducerade en kurva med exakt samma namn (Curve25519) som dock inte var samma kurva som den kurva som normalt kallas Curve25519. Men nu finns till slut två nya kurvor framme.

Vad är det då som specificerats? Det är två kurvor, Curve25519 med 256 bitars nyckel med 128 bitars säkerhet och kan sägas vara en direkt ersättning till P256. För de som kräver ytterligare säkerhetsnivå finns kurvan Curve488 med 448 bitars nyckel och 224 bitars säkerhet. I RFC:n finns även med de så kallade Twisted Edward Curve-versionerna av kurvorna. Detta gör det möjligt att använda kurvorna inte bara för nyckelutbyte, utan även för signering och kryptrering. De nya kurvorna är flera gånger snabbare än NISTs kurvor och det finns redan i dag bra implementationer som inte har problem med sidoläckage.

När nu kurvorna finns kommer förhoppningsvis fler att börja använda EC. Inte minst för inbyggda system är blir de här kurvorna klart snabbare och mer kompakta än att använda RSA med nycklar på mer än 3000 bitar. När TLS 1.3 publiceras kommer det även att finnas nya kryptosviter med mycket snabbare symmetriska krypton (exempelvis Salsa20 och ChaCha) samt MAC-funktioner som Poly1305. Då kommer behovet av snabba asymmetriska primitiver att bli än viktigare.

En av de personer som jobbat hårt för att få fram nya kurvor är Simon Josefsson. Tack Simon för bra jobb!

 

Cryptechs årsrapport för 2015

Joachim Strömbergson

Assured arbetar i det öppna HSM-projektet Cryptech. I slutet av december släpptes Cryptechs årsrapport för 2015. (pdf).

Bland de saker som åstadkommits under året kan nämnas en lösning för att signera DNSSEC-zoner inklusive att generera nycklar. Denna lösning använder Novenakortet med Cryptechs egna bruskälla som bas och sedan Cryptechs FPGA-design samt programvara. DNSSEC-signeringslösningen använder PKCS#11-kommandon och kan därför även användas för ett antal andra syften där HSM:er används med PKCS#11. Hela lösningen finns paketerad i Deb-paket för de som inte vill bygga lösningen själv utifrån den källkod Cryptech tillhandahåller.


Det stora arbetet som pågår i Cryptech i dag är att lämna Novena och använda Crypytechs första helt egna kort - Alphakortet (pdf). Detta kort är en mer renodlad HSM-design med möjlighet att bygga aktiva skalskydd. De första prototyperna av Alphakortet berräknas vara framme i första kvartalet 2016. Just nu försöker vi färdigställa Alphakortets elschema (pdf). Om du ser några fel eller har några kommentarer skulle projektet uppskatta att få dessa postade på tech-listan.

Cryptech är ett öppet projekt som finansieras av ett antal organisationer och företag. I årsrapporten finns mer information om vem som finansierar projektet och hur pengarna använts under 2015.

Cryptech open cryptech hackday

Joachim Strömbergson

On July 18, right before the IETF 93 meeting, the Cryptech project will organize an open hackday in Prague.

This is a great opportunity to become acquainted with the CrypTech software platform using the novena development boards. There will be a limited number of Novena boards available to play with during the workshop. We will focus on DNSSEC signing as a use-case. You will also be able to talk with the Cryptech team about the project as a whole as well as technical details. If somebody wants to have GBytes of random data we can provide that too.

The workshop program can be found here.

The hackday happens the day before IETF 93 and will take place at the venue for IETF 93.

See you in Prague!

/JoachimS

Security of Encryption in Web Frameworks

Peter Magnusson

A number of web frameworks and standards incorporate encrypted user data, where the security assurance is built on the assumption "if it was encrypted by the server, it is trustworthy".

We know these features by many names: ViewState, Encrypted Beans, Encrypted Parameters, Authentication Cookies, MessageEncryptor. 

Why web encryption frameworks are interesting and possibly dangerous:

1) There is a presumed level of trust because it is encrypted. And if it is presumed trustworthy, developers will think it is okay to dangerous things based on it. (Hacking .NET with forged Authentication Cookies)

2) There is often an unclear threat model and security contract between application developers and framework. I don't believe I ever have read a framework documentation which clearly says what programming contract an application developer must follow to not break security. And the framework developers may change the security contract in future releases.

  • Stripes 1.4.x encrypted with a unique key per session, Stripes 1.5.x encrypts with a global key; which changes the security requirements on application source code - a web site which relied heavily on Stripes 1.4.x security model could be much less secure after been upgraded to Stripes 1.5.x.
  • Framework developers may choose to increase security to defend against attacks, possibly changing the programming contracts and causing problems for legacy application built under different behaviours.

3) Audit and verification is next to non-existent. Your average penetration tester is often not skilled in evaluating encryption solution. And developers & code auditors may have a hard time evaluating correctness of application code because there is no contract. Almost all web penetration testers knows how to look for SQL injection, most don't understand encryption at all. And application developers and framework developers alike, most aren't cryptography experts. 

Threats to web encryption frameworks:

Choosen ciphertext attacks: The attacker would love to be able to mount attacks which allows the attacker to generate valid ciphertext using tampering attacks (funny example, check out "CAPTCHA graffiti"). 

Choosen plaintext attacks: The attacker would love to be able to just create ANY plaintext. In some frameworks, it is actually crazy easy for an application developer to accidentally create an choosen plaintext vulnerability; they only need to create one web page which returns an encrypted copy of a user controlled input. A single application developer flaw may undermine the security of the web framework.

Cross-Site Request Forgery attacks: An hacker may observe the encrypted parameters for an important web transaction, and then launch classic CSRF attack. This attack works brilliantly against many frameworks :)

Protecting against web encryption threats:

Application developers should, unless they have very good reasons to believe otherwise, assume that encrypted data is not trustworthy data,

Framework developers should implement encryption best practices, such as authenticated encryption. That means either doing AEAD ciphers such as AES-GCM, or do Encypt-then-Mac (HMAC of ciphertext). TODO: write a blog post on this subject.

Framework developers should limit scope of encryption. For example, CSRF attacks against encrypted parameters works because two different sessions can encrypt and decode each others parameters. Defining the scope (per page? per session? per user?) and enforce scope limitation can make the framework robust enough defend against some vulnerabilities in application code and web browsers.

How to limit scope of encryption:

A web framework could limit encryption scope by having a unique key per scope

  • A simple way of doing this is to create a random encryption key, and put it into the server-side HTTP Session. Under a set of assumption, i.e. a session for each user is acceptable, and session hijacking is otherwise prevented, this acceptable.
  • Another way is to perform Key Derive per scope, with scope included in the PBKDF salt/context, to generate scope unique keys in runtime.

Another way for web frameworks to limit encryption scope could be to include scope in the plaintext and reject any decrypted plaintext originating from the wrong scope. For example, a framework create encrypt application plaintext as such follows:

  • plaintext =  BASE64(scope) + ":" + application_plaintext.
  • ciphertext = authenticated_encryption( plaintext ).

And decrypt as follows:

  • plaintext = authenticated_decryption( ciphertext ).
  • if ( not plaintext.startWithBASE64(scope) + ":"  ) throw new EncryptionBadScopeException

Cryptech moving towards the Alpha board

Joachim Strömbergson

Assured is involved in the Cryptech HSM project. This is a short blog post about some of the latest activities and ongoing work in the project.

The Cryptech HSM project is currently using the Novena as the platform. The Novena is a very nice, open platform that allows us to work in a Linux based environment. After some struggles there is now a working high speed, low latency interface between the CPU and the FPGA on the Novena. This allows us to start using the Cryptech cores as coprocessors from SW running on the main CPU. This means that we can start doing some real work with Cryptech as a HSM (Hardware Security Module).

The random number generator has been extensively tested the last months. And the results indicates that we have two really good entropy sources that drives a CSPRNG chain capable of delivering high quality random numbers at very high data rates.

The next step for Cryptech on the Novena is to get all functionality for our first major use cases up and running. This includes RSA as well as ECDSA sign and verify. We also need to get the P#11 API working to allow applications to use the HSM. This will be done on the Novena. See the Dashboard for more information about status and the use cases and functionality we will deliver in short term.

In parallel with this work we are also moving forward with the first custom designed platform - the Alpha Board. This board is closely related to the Novena, but with a lot less appliances. The board also sports a MUCH bigger FPGA and an even faster interface between the FPGA and the CPU. This board also includes functionality needed to start develop real active tamper detection and protection mechanisms.

The Cryptech Alpha board functional block diagram.

The Cryptech Alpha board functional block diagram.

Finalists in the Password Hashing Competition

Joachim Strömbergson

There are many ways of generating keys from a password being used in the world. Unfortunately most of them are insecure and weak. Typical problems is using unsalted cryptographic hash functions such as MD5 or SHA-1. This opens up to precomputation based attacks called rainbow attacks. There are even web service and bots on Twitter that can find the password for you:

Test of online hash cracker service with the md5 sum for the string "hello".

Test of online hash cracker service with the md5 sum for the string "hello".

There are couple of standard, most notably PBKDF#2 as specified in RFC 2898. One algorithm often pointed to is bcrypt based on the Blowfish block cipher. Bcrypt provides good resistance to rainbow attacks, but can also scale computationally wise to mitigare increasing computation power. But bcrypt does not have a mechanism for handling compute-memory tradeoffs. The Scrypt algorithm is a later development that provides the ability not only to brute force computation requirements, but also memory requirements.

So basically we have three algorithms of which only one provides strong resistance against large scale hardware based attacks.

In order to improve the situation, and also better support a wider array of applications, for example web services, PIN authentication on mobile devices, key derivation for full disk encryption, or private keys encryption, a group of cryptographers started the Password Hashing Competition (PHC). PHC was started in 2014 with a call for submissions. A total of 24 candidates was submitted. From the candidates nine candidates have now been selected: Argon, battcrypt, Catena, Lyra2, Makwa, Parallel, POMELO, Pufferfish and yescrypt.

Criteria used during evaluation has been:

  • Defense against GPU/FPGA/ASIC attackers
  • Defense against time-memory tradeoffs
  • Defense against side-channel leaks
  • Defense against cryptanalytic attacks
  • Elegance and simplicity of design
  • Quality of the documentation
  • Quality of the reference implementation
  • General soundness and simplicity of the algorithm
  • Originality and innovation

The candidate evaluation report gives a good presentation of the nine finalists and the candidates that didn't make it to the final. The next step in PHC is to select one or more finalist as recommended algorithms. This selection is to be done in Q2 2015. We at Assured follow the PHC and look forward to the final algorithms.

 

Assured's Web Penetration Testers

Peter Magnusson

Assured is extremely proud of its team of web penetration testers. Why? Well, we deliver quality tests!

Within the security community, we all dread the fact that many companies simply run a tool and takes its automated findings for truth. Such malpractice is wasting non-security staffs time with garbage output, and also is completely unable to provide any feedback on what could not be properly tested.

A great penetration tester needs to be able to combine automation with manual verification and manual search for what the automation does not find. The end game is to provide a customer with a great security assessment and also be able to give feedback on how well / extensively the application is tested. 

We provide great penetration tests this with our three application security experts: Johan Rydberg Möller, who from early on has focused most of his time on getting great at web penetration tests. Jonas Magazinius, who hold a PhD in Computer Science with focus on web application security, and close collaboration Peter Magnusson, who has been working with secure software development & testing since 2003.