Taggat med: rsa

Nyheterna i Transport Layer Security version 1.3 (TLS 1.3)

 

SSL och TLS har under lång tid säkrat upp en betydande del av den krypterade kommunikationen på Internet. Sedan SSL version 1.0 släpptes internt hos Mozilla år 1994 så har det hänt en hel del.

Den nya versionen som just nu håller på att utvecklas inom en arbetsgrupp hos IETF har versionsnumret 1.3 där målsättningen är högre prestanda samt tillhandahålla en ännu högre säkerhet. Man kan säga att designkriteriet för denna nya version är ”less is more” och det innebär att en hel del föråldrade krypton har fått stryka på foten:

  • RSA är borttaget – Tillhandahåller inte Forward Secrecy
  • Svaga Diffie-Hellman grupper kan inte användas (SSL_OP_SINGLE_DH_USE)
  • CBC är borta – Är orsaken till attacker såsom Lucky13 och BEAST
  • RC4 samt SHA1 får inte längre användas
  • Export-algoritmer (ansvarig för attacker såsom FREAK, LogJam etc)
  • Nytt är ChaCha-Poly1305 samt stöd för OCB-modes (tipstack till Joachim Strömbergson)

När det gäller prestanda så har ett antal åtgärder införts:

  • 0-RTT samt 1-RTT

Genom att få ner antalet TCP-paket som måste skickas fram och tillbaka vid varje anslutning så kan snabbare TLS (och webbsidor etc) uppnås.

Här följer en bild hur 1-RTT ser ut där klienten skickar ett ClientHello direkt, samt så gissar klienten vilka krypton som kommer att användas:

När du sedan har en session etablerad så kan sedan 0-RTT användas vid senare tillfälle (Session Resumption) men detta möjliggör dock återuppspelningsattacker.

Vill du redan nu testa TLS 1.3 i Google Chrome så kan du göra följande:

  1. Skriv in ”chrome://flags/” i adressbaren och trycker enter
  2. Gå till ”Maximum TLS version enabled.” och välj ”TLS 1.3”
  3. Starta om Chrome

Och vill du testa med Firefox så behöver du ladda hem senaste nightly-build där TLS 1.3 är påslaget som standard.

Och nu när vi besöker kryptera.se och tar upp Developer Tools (DevTools) så synes följande:

Viktigt att tillägga är att TLS 1.3 inte är färdigt ännu och ändras löpande. Detta gör att mjukvara såsom OpenSSL är försiktiga med att göra förändringar. Den senaste uppdateringen till TLS 1.3 heter draft-19 och släpptes för cirka 2 veckor sedan.

För att exempelvis Nginx ska stödja TLS 1.3 så måste även OpenSSL stödja detta. Och OpenSSL kommer med stöd inom några veckor i version 1.1.1.

Granskning av IT-säkerheten på Dagens Nyheters (DN) tipssajt

Jag har genomfört en oberoende granskning av IT-säkerheten på DN:s sajt där användare kan skicka in tips. Tidigare har jag bl.a. granskat SVT:s TV-leaks. Min förhoppning är att fler kan dra lärdomar och således blir säkerheten bättre i längden.

All information nedan är sammanställt med hjälp av öppen information.

Peter Wolodarski som är chefredaktör på DN framhäver på sajten dngranskar.dn.se följande (se även skärmdump ovan):

Vi behöver din hjälp i vårt arbete. De största avslöjandena kommer från människor som har värdefull information. DN lägger stora resurser på granskande journalistik. Här kan du på ett säkert sätt lämna tips till våra undersökande reportrar.

Vidare så läser vi även följande:

Tjänsten är skyddad med hög kryptering för att ge dig som tipsare största möjliga säkerhet. Det innebär att tipset blir oläsligt utan en särskild nyckel. Bara ett begränsat antal reportrar på tidningen har tillgång till denna nyckel.

Denna särskilda nyckel som ovan text refererar till är en PGP-nyckel som ligger inbäddad på webbsidan. Denna nyckel läses sedan av openpgp.js och formulärdata krypteras och skickas över och lagras på serversidan.

Den publika PGP-nyckeln som återfinnes på sidan ser ut enligt följande:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP.js v1.3.0
Comment: http://openpgpjs.org

xo0EViaQEAEEAKGUFnG9PCA3tWCcj2+e6GgRzTSY7hbN5YYurJbNeHsE4SbT
UPHQzGKQsqcyYieIS9Uh/co42E1ndgG4xZSjRZslMWRkTQVCEGTCMPzm0sSE
P8zGndzF/R//FK4AvshSUBa8sLWTp026C2xqAhIvUOvKwRBK9PKclfKZVV/5
zG8zABEBAAHNMktyaXN0b2ZmZXIgw5Zyc3RhZGl1cyA8a3Jpc3RvZmZlci5v
cnN0YWRpdXNAZG4uc2U+wrIEEAEIACYFAlYmkBAGCwkIBwMCCRBMNmcxb9M1
+QQVCAIKAxYCAQIbAwIeAQAAOH0D/1RUQSjmYhkUoGkwLp5HF7Xl6UDYQpoX
8Xdhjb5Aufu/nUgs73nXS2MlycqHqoKGV0a43PzteujQz9gz86nIHrdB7F7l
jLlssUSzD2oePObv4wpK9lBee9HZs980+LWkK3t3yUe6+mixsspZvEAGe/Q0
k50JgxMHFcfj5uCTm3fTzo0EViaQEAEEALCZMwq4sfm59Hq5Z4hOv8pdPtMX
jy26WZBBaZ8csv54UWm7o7Xt2TRkU1eGR6j/UjAXVNZ6jKON10M8I+1nmlpx
ZtS3I9QRja7N0HOn/Mo9et5bHdZKQSHUd1vblRRddHOqU+C4EP+BAKqtR/Ne
y6RxOCaydspT+wJzWCS8dfarABEBAAHCnwQYAQgAEwUCViaQEAkQTDZnMW/T
NfkCGwwAAM/nA/9Ra0Mnr2cIOOFXN/TAeLK0JKG9s/hIa01zGMC9dDub5Q1r
zAiVO/c664MYvtbOOMOf5VeHRPBiVFuxw3Fl4MzX0g61bcHBTMKaT6iF+13l
3zONpw81eAh1fjN8PX4gcwrU6W+N4BTSBHO+3dMWNF9rlK/xGfqLzvXAo+zL
OCbglg==
=Bf3n
-----END PGP PUBLIC KEY BLOCK-----

Den med ett tränat öga ser att ovan nyckel inte ser ut att vara speciellt lång, nämligen enbart 1024-bitar RSA, vilket inte är att rekommendera sedan år 2010. Tittar vi närmare på nyckeln så ser vi även att den står på Kristoffer Örstadius.

Även något som är anmärkningsvärt så används inte denna nyckel när jag testar att skicka in ett tips med Firefox, då ser kommunikationen ut enligt följande:

Gör jag samma med Google Chrome så krypteras all information från formuläret med 1024-bitars nyckeln förutom filnamnet:

Tittar vi på webbservern så svarar den att det är en gammal Apache, openssl med en PHP-version som är end-of-life sedan 2015, dvs inga säkerhetsuppdateringar eller liknande kommer. Red Hat tillhandahåller säkerhetsfixar för dessa versioner efter noggrann kontroll:

Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips PHP/5.4.16

Övriga saker att anmärka på är även att cookies för spårning och annonsering följer med från dn.se till dngranskar.dn.se såsom _ga (Google Analytics), optimizelyEndUserId, __couid (Kantar Sifo) och _burtAgency. Openpgpjs som används är version 1.30 och den senaste är 2.3.6.

Även bör headers som meddelar att webbläsare inte bör cacha innehåll användas såsom:

  • Cache-control: no-store
  • Pragma: no-cache

Sajten från A+ från SSLlabs.com vilket är bra och inga tredjepartsscript eller liknande laddas in.

Sammanfattning

Tjänsten är byggd med flertalet IT-säkerhetsbrister. Kommunikationen går över TLS vilket räddar upp situationen en del men informationen lagras troligtvis i klartext på servern när openpgp.js inte fungerar som den ska.

Jag har kontaktat DN innan publiceringen av denna granskning och DN meddelar att en ny sajt lanseras inom kort. Att titta på för inspiration för framtida arbete är SecureDrop som bl.a. The Guardian och NY Times använder.

Uppdatering: DN meddelar att kryptering även genomförs på serversidan av informationen efter den är inskickad.

SecureDrop över Tor som The New York Times använder sig av

Uppdatering: Burp Suites passiva granskning rapporterar 11 st medium-brister och 42 st low:

NSA varnar för kvantdatorer

 

NSA Kvantdatorer

Eller rättare skrivet så gick den amerikanska myndigheten NSA ut för några dagar sedan och varnade för att många av nutidens algoritmer som används bör uppgraderas för att motstå beräkningar utförda av kvantdatorer.

Det rör framförallt RSA där nyckelstorlekar  är under 4096 bitar, men även elliptiska kurvor kan ligga dåligt till eftersom en variant av Shors algoritm kan användas. Eller som NSA uttrycker det:

Minimum 3072 bit-modulus to protect up to TOP SECRET.

Intressant också är gällande hashalgoritmer så rekommenderas minst SHA384, vilket i praktiken innebär SHA512.

Nu innebär detta inte att alla måste byta över en natt utan NSA rekommenderar att leverantörer slutar att leverera och tillverka produkter eller mjukvaror som implementerar algoritmer som ej kan motstå beräkningar utförda av kvantdatorer.

Och förutom RSA och SHA så rekommenderas ECDH (Elliptic Curve Diffie–Hellman) med med minst 384 bitar.

Personligen så föredrar jag Curve25519 av Daniel J Bernstein etc, se SafeCurves. Bitcoin exempelvis använder sig av secp256k1.

The RSA-2048 Challenge Problem would take 1 billion years with a classical computer. A quantum computer could do it in 100 seconds

– Dr. Krysta Svore, Microsoft Research

Facebook + PGP = ❤️

Facebook PGP

Facebook stödjer nu att du kan ladda upp din publika nyckel till din Facebook-profil. Då kommer Facebook att använda denna nyckel när de skickar ut meddelanden via E-post.

Och som ovan bild visar så förhindrar detta även om ditt E-postkonto skulle bli kapat (men du använder väl tvåfaktorsautentisering också?).

Behöver ditt företag hjälp med IT-säkerhet eller kryptering? Kontakta Triop AB >

Detta är så klart ett bra uppsving för hela PGP och web of trust och detta märks tydligt då flertalet nyckelservrar såsom pgp.mit.edu svarar långsamt idag eller är helt nere. En tydlig koppling mellan din Facebook-profil och nyckel stärker förtroendet, lite åt det håll som tjänsten Keybase är tänkt.

För att bekräfta att din publika PGP-nyckel så skickar Facebook även ut ett krypterat verifieringsmail med en länk som du måste klicka på för att funktionen ska aktiveras.

Om du vill ladda hem någons publika PGP-nyckel så kan du göra det enligt följande exempel på URL:

https://www.facebook.com/facebookalias/publickey/download

Facebook PGP

Här laddar du upp din publika nyckel:

https://www.facebook.com/me/about?section=contact-info

Facebook själva använder en nyckel med följande fingerprint:

31A7 0953 D8D5 90BA 1FAB 3776 2F38 98CE DEE9 58CF

och denna subkey fingerprint:

D8B1 153C 9BE9 C7FD B62F 7861 DBF4 E8A2 96FD E3D7

Och Facebook kommer att stödja RSA och ElGamal men undersöker huruvida de även kan stödja elliptiska kurvor (ECC). Obligatorisk XKCD:

XKCD PGP

Tips! Gillade du att läsa detta? Kolla även in: Facebook finns nu på Tor

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

Allvarlig sårbarhet i Microsoft Schannel

microsoftIgår släppte Microsoft sina månatliga patchar för November och en av de mer allvarligare sårbarheterna som åtgärdas medger kodexekvering över nätverket (MS14-066).

Sårbarheten som åtgärdas återfinnes i Microsoft Secure Channel (Schannel) och är den del som hanterar SSL/TLS. Denna sårbarhet gäller enbart Windows Server men Microsoft patch även inkluderar Windows 7 och 8.

Tyvärr så framgår inga temporära åtgärder som kan genomföras för att förmildra en eventuell attack (workarounds).

Även så har Microsoft uppdaterat sina cipher suites och stödjer nu Galois/counter mode (GCM) samt perfect forward secrecy med hjälp av DHE + RSA.

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256

Läs mer här:  technet.microsoft.com/library/security/ms14-066

Kryptering i Apple iOS: iMessage, AirPlay och AirDrop

Apple har nu släppt ett dokument som beskriver säkerheten i operativsystemet iOS. Detta dokument är omfattande och är på hela 33 sidor.

I dokumentet beskriver bl.a. att iOS använder sig  av ARM-processorns funktion vid namn Execute Never (XN) för att markera pages som icke exekverbara. Även så använder Safari webbläsaren denna för sin JavaScript JIT-kompilerare. Detta för att försvåra exploitering.

iMessage kryptering

Apple avänder sig av DJB:s Curve25519 (ECDH) samt RSA och AES en hel del, exempelvis för iMessage-kryptering:

When a user turns on iMessage, the device generates two pairs of keys for use with the service: an RSA 1280-bit key for encryption and an ECDSA 256-bit key for signing.

AirPlay kryptering

Även hur AirPlay använder kryptering beskrivs:

AirPlay audio and video streams utilize the MFi-SAP (Secure Association Protocol), which encrypts communication between the accessory and device using ECDH key exchange (Curve25519) with 2048-bit RSA keys and AES-128 in CTR mode

AirDrop kryptering

När en användare slår på AirDrop så skapas en 2048-bit RSA-nyckel som sedan används för TLS-kommunikation över Bluetooth Low-Energy (BTLE) eller WiFi. Ingen accesspunkt eller Internetanslutning behövs för att använda AirDrop. Verifiering av vem som skickar genomförs genom kontroll mot kontaktlistan ”Contacts Only”.

iOS Security

Page 3 Introduction
Page 4 System Security
Secure Boot Chain
System Software Authorization
Secure Enclave
Touch ID
Page 8 Encryption and Data Protection
Hardware Security Features
File Data Protection
Passcodes
Data Protection Classes
Keychain Data Protection
Keybags
FIPS 140-2
Page 14 App Security
App Code Signing
Runtime Process Security
Data Protection in Apps
Accessories
Page 17 Network Security
SSL, TLS
VPN
Wi-Fi
Bluetooth
Single Sign-on
AirDrop Security
Page 20 Internet Services
iMessage
FaceTime
Siri
iCloud
iCloud Keychain
Page 27 Device Controls
Passcode Protection
Configuration Enforcement
Mobile Device Management (MDM)
Apple Configurator
Device Restrictions
Supervised Only Restrictions
Remote Wipe

Dokumentet kan du ladda hem här:

GNU Nettle

Pandaboard

Förra året så fick Niels Möller på South Pole AB pengar från Internetfonden för att anpassa krypteringsbiblioteket GNU Nettle för inbyggda system.

Målet med projektet var att göra kryptering med hjälp av GNU Nettle mer effektivt för inbyggda system och mobila enheter (framförallt ARM-processorer). De två konkreta delmålen för projektet är:

  • Att implementera digitala signaturer baserade på elliptiska kurvor (ECC). Jämfört med traditionella digitala signaturer med RSA, så ger elliptiska kurvor motsvarande säkerhet med betydligt mindre processortid. Även minnesåtgång, både för själva beräkningen, och för nycklar och signaturer, är betydligt mindre.
  • Att optimera andra viktiga kryptografiska byggstenar, som krypteringsalgoritmen AES och hashfunktionerna SHA1 och SHA256, för ARM-arkitekturen.

Plattformen för testar var en en Pandaboard med en 1 GHz ARM Cortex-A9, och operativsystemet Debian GNU/Linux.

Här kan du ladda hem slutrapporten: Slutrapport-GnuNettle-Moller.pdf eller läs mer på Internetfonden.se.

Har du ett projekt som söker finansiering? Kanske inom krypteringsområdet? Varför inte söka pengar från Internetfonden. Sista ansökningsdag är 11:de September 2013.

Kryptouppdateringar i Microsoft Windows

Windows krypteringMicrosoft meddelade för ett tag sedan att man avser att stärka krypteringen i Windows under perioden 2012-2013 och nedan kan du se några av förbättringarna som håller på att införas.

Många av dessa förändringar är redan inbyggda i Windows 8 samt Windows Server 2012 och är även nu åtgärdade för att fungera på äldre operativsystem.

Generellt så gäller förändringarna vilka krypteringsalgoritmer som används men även längden på nycklar.

Microsoft Security Advisory 2661254
This update set a mandatory key length for RSA keys of 1024 bits or stronger by restricting the use of certificates with RSA keys less than 1024 bits in length.

Microsoft Security Advisory 2813430
This update establishes functionality that enables consumers to update trusted and disallowed Certificate Trust Lists (CTL) in non-internet connected environments. CTL’s are a list of approved hashes or certificates approved by a trusted third party. This update allows customers more control in which parties they trust.

Microsoft Security Advisory 2862966
This update established a framework for managing asymmetric cryptography by adding features for monitoring and directly controlling which cryptographic algorithms are used (RSA, DSA or ECDSA), options to set minimum key length as well as to set which hashing algorithms will be permitted for code signing and other functions. All functionality is documented in detail on Microsoft TechNet.

Microsoft Security Advisory 2862973
This update released today as Downloadable Content (DLC) gives customers the option to restrict the use of certificates that utilize the MD5 hashing algorithm as part of their digital signature. We recommend that customers download and test the update in their environment at the earliest opportunity, this will be especially useful for environments that have little or no inventory of their cryptographic and certificate dependencies. This update will only affect MD5 as used in server authentication, code signing and time stamping. There are exceptions for certain certificates and timestamps, please see KB 2862973 for additional details. Microsoft is planning to release this update through Windows Update on February 11, 2014 after customers have a chance to assess the impact of this update and take necessary actions in their enterprise.

MSB Trendrapport – samhällets informationssäkerhet 2012

MSBMyndigheten för samhällsskydd och beredskap (MSB) har idag släppt en rapport vid namn Trendrapport – samhällets informationssäkerhet 2012. Rapporten är övergripande och omfattande och tar upp ett antal större händelser som inträffat under de senare åren såsom Anonymous, Stuxnet, E-legitimation och sociala medier.

Det vi finner är intressant är två kapitel som handlar om SSL-certifikat samt intrånget mot företaget RSA. Gällande angrepp mot bl.a. DigiNotar och SSL generellt så reflekterar MSB enligt följande:

– Att den teknik som används för att utfärda äkthetscertifikat till  webbplatser är känslig har varit känt under en längre tid. Det finns idag drygt 600 olika företag som agerar som centrala certifikatutfärdare, och det finns risker förknippade med en sådan mångfald av äkthetsintyg. Många tekniska bedömare betraktar redan den PKI-struktur (”public key infrastructure”) som används som otillförlitlig och en återvändsgränd. Skulle det visa sig att ytterligare falska  webbplatscertifikat inom kort kommer i omlopp så skulle det på sikt kunna minska tilltron till dataintegriteten hos ett stort antal webbtjänster i världen som förlitar sig på SSL. Det arbetas emellertid på lösningar. En av dem är att transportera certifikat via domänsystemet DNS, en metod som håller på att standardiseras av arbetsgruppen DANE inom internets standardiseringsorganisation IETF.

Klicka på rapporten nedan för att läsa den i sin helhet:

 

MSB Trendrapport 2012