GnuPG dicht lek in encryptiebibliotheek dat achterhalen rsa-sleutel toelaat

Verschillende wetenschappers, onder wie onderzoekers van de TU Eindhoven, hebben een lek gevonden in de encryptiebibliotheek libgcrypt, die in GnuPG aanwezig is. Er is een patch uitgebracht voor de kwetsbaarheid die het achterhalen van een 1024bit-rsa-sleutel mogelijk maakt.

Het onderzoek, dat werd opgemerkt door The Register, spreekt van een side channel-aanval die het achterhalen van een 1024bit-sleutel mogelijk maakt. Hetzelfde is mogelijk voor een 2048bit-sleutel, waarvoor wel meer rekenkracht is vereist. De kwetsbaarheid heeft te maken met het gebruik van een 'sliding window'-methode voor machtsverheffing die informatie lekt. Om de kwetsbaarheid aan te tonen, maakten de onderzoekers gebruik van een zogenaamde 'flush + reload'-aanval op het geheugen van een systeem.

GnuPG-ontwikkelaar Werner Koch schrijft bij de aankondiging van de patch dat de aanval ervan uitgaat dat de aanvaller in staat is om zelfgekozen software op de hardware van een systeem te draaien, wat veelal als een game-over-scenario wordt beschouwd als dat gebeurt op een machine met privésleutels. Daarom zouden er eenvoudigere manieren zijn om de sleutel te achterhalen. De aanval zou echter wel toepassing hebben bij verschillende virtual machines die een gedeeld geheugen hebben. Dit is overgenomen in het advies van het NCSC.

Volgens Packet Storm zijn er patches voor Debian en Ubuntu voor het lek met kenmerk CVE-2017-7526 en ook Fedora heeft een patch beschikbaar. GnuPG staat voor GNU Privacy Guard en wordt ook vaak afgekort tot GPG. Dit is een verzameling tools voor het beveiligen van communicatiestromen en data. Het kan worden gebruikt om data te versleutelen en digitale handtekeningen aan te maken, en voor het aanbieden van een framework voor public key-cryptografie. Het ondersteunt zowel OpenPGP als s/mime-standaarden. De TU Eindhoven-onderzoekers die aan het onderzoek hebben meegewerkt zijn Tanja Lange, Christine van Vredendaal en Leon Groot Bruinderink.

Reacties (17)

Ter info voor Ubuntu. Deze versies moet je hebben (bevat de patch):

Ubuntu 17.04: libgcrypt20 1.7.6-1ubuntu0.1
Ubuntu 16.10: libgcrypt20 1.7.2-2ubuntu1.1
Ubuntu 16.04: libgcrypt20 1.6.5-2ubuntu0.3
Ubuntu 14.04: libgcrypt11 1.5.3-2ubuntu4.5

Checken welke versie je hebt kan via commando:
apt-cache policy libgcrypt11 (Ubuntu 14.04)
apt-cache policy libgcrypt20 (Ubuntu 16.04+)

Bron: https://www.ubuntu.com/usn/usn-3347-1/

[Reactie gewijzigd door JointFillah op 4 juli 2017 10:56]

Voor andere distributies:
Versie 1.7.8 (de huidige stable) lost het probleem in de library zelf op zonder patches. Deze versie is uitgekomen op 29 juni 2017.

Voor Arch Linux gebruikers is deze update al beschikbaar sinds 30 juni voor core package libgcrypt. Er is nog geen update uit voor community package libgcrypt15. Het advies is dus om de laatste versie te gebruiken. Normaliter zal bij GnuPG gebruik alleen package libgcrypt geïnstalleerd zijn.

[Reactie gewijzigd door The Zep Man op 4 juli 2017 11:47]

Goed dat dit al zo snel gepatcht is! Ik gebruik GPG veel, niet voor email maar voor encryptie van backups e.d. van online servers.

Maar mijn keys staan op smartcards dus dit lek is daar niet van toepassing op (want de computer heeft nooit de private key in handen, deze blijft op de kaart). Hij wordt zelfs op de kaart gegenereerd. Voordeel is ook dat de kaart zichzelf blokkeert na 3 foute PIN pogingen (net zoals een pinpas) dus je kan ook de PIN niet bruteforcen zoals dat met een gewone private key wel kan.

Hier kan je die kopen: De gewone versie met alleen contact of de Fidesmo versie met NFC en contact (werkt ook op Android met OpenKeyChain). Met de Fidesmo kaarten moet je nog wel de OpenPGP applet kopen en installeren voor een paar euro. Ook heb je versies met alleen NFC.

[Reactie gewijzigd door GekkePrutser op 4 juli 2017 20:38]

Ook leuk dat die shop (kernelconcepts.de) die je linkt https serveert met een verlopen certificaat... dat wekt vertrouwen

Klopt, er stond al dat hij in onderhoud was, maar ik zie nu dat ze een nieuwe shop gestart zijn onder een andere naam: https://www.floss-shop.de/. Vandaar dat hun cert ook verlopen is (en oude technieken gebruikt). Ik heb er al jaren niet meer besteld.

Overigens zou ik tegenwoordig liever voor de Fidesmo gaan. Inclusief de OpenPGP applet is hij even duur en hij heeft zowel contact als draadloos (RFID) en dat is tegenwoordig superhandig. Ook kan je er nog andere applets op zetten ook zoals een bitcoin wallet.

Ik gebruik het ook veel voor inloggen met SSH (public key login met de private key op de kaart). daar gebruik ik het nog een stuk vaker voor dan file encryptie. En er is nu ook een app die SSH op Android kan met smartcard dus dan is die NFC echt heel handig.

[Reactie gewijzigd door GekkePrutser op 4 juli 2017 20:55]

Wat ook van belang is is dat als je op versie 1.4 gebruikt (bijvoorbeeld wegens backwards compatibility omdat de ondersteuning voor pgp v3 keys verwijderd is uit de 2.1 branch) je niet kwetsbaar lijkt te zijn, deze gebruikt geen libgcrypt. Voor de zekerheid heb ik het nog nagevraagd op de GnuPG mailing list, ik wacht op antwoord.

Edit: ondertussen heb ik antwoord terug:

> Is 1.4 vulnerable to this attack as well? I know it does not use
> libgcrypt but I'm not sure about the vulnerability.

Maybe. And probably also to a lot of other local side channel attacks.

Shalom-Salam,

Werner

Mijn vervolgvraag is of hier nog iets aan gaat gebeuren.

[Reactie gewijzigd door Morgan4321 op 4 juli 2017 21:26]

Maar moet je dan ook nieuwe sleutel genereren?

Wellicht dat het een goed moment is om je sleutels een goed aan te pakken.

• Genereer een 4k rsa sleutel (offline met bv een livecd)
• optioneel plaats de 4k private key op een smartcard (bv yubikey/opengpgcard)
• maak een veilige backup van de privatekey
• genereer een subkey (2k)
• genereerd een revoke certificaat
• verwijder de 4k private key
• publiceer de 4k public key
• gebruik de 2k key
• indien compromised, ga offline en gebruik de backup van de 4k private key om een nieuwe 2k key te genereren

Wat is het voordeel van een RSA sleutel boven een ElGamal key? Ik gebruik zelf een 3k ElGamal. Wat ik er van weet is dat als het discrete log probleem opgelost wordt (ElGamal is dan kwetsbaar), dat dan het factoringprobleem ook opgelost is (RSA kwetsbaar); andersom werkt dat waarschijnlijk niet zo (de eerste stap is bewezen, de tweede (nog?) niet). Sterker dan 3k is ook niet zo zinvol omdat dan de session keys zwakker worden dan de symmetrische sleutel (uitgaande van 128 bits, sterk zat IMO).

De meeste zijn praktisch. RSA is een veelgebruikte standaard en wordt vaak standaard ondersteund. De berekening maakt gebruik van simpele mathematische functies die eenvoudig in hardware te implementeren zijn. Elgamal heeft floating point en log functionaliteit nodig.

Smartcard support is er wel voor RSA. Verder is RSA/RSA de default boven DSA/Elgamal, daar zal vast een goede reden voor zijn (net zoals openssh DSA default disabled heeft).

RSA lijkt nog steeds het meest 'standaard' en geaccepteerd te zijn, ook al heb je grote keys nodig. ECDSA is natuurlijk een stuk efficienter omdat je aan 256 bits keys genoeg hebt.

@Belgar: Dat is niet waar, voor ElGamal heb je zeker geen floats of logarithms nodig. En als je het over elliptic curves doet is het juist veel praktischer omdat je met veel kleinere getallen werkt.

@Dorank Het klopt dat openssl DSA niet meer ondersteund, maar de reden daarvan is 'n beetje vaag. Het lijkt erop dat de belangrijkste reden is dat iemand gewoon een maximum key size er in heeft geprogrammeerd (link). ECDSA wordt gewoon ondersteund.

Lijkt me logisch van niet, tenzij die al gecompromitteerd is natuurlijk.

En hoe weet je dat?

Zie het artikel. Om hier gebruik van te maken moet de aanvaller speciale software draaien op het systeem waar je keys al op staan. Als dat met je thuis PC het geval is dan zijn je keys toch al niet meer veilig, gepatchte GPG of niet. Want dan kan die aanvaller ook gewoon je GPG keystore uitlezen. Key paswoord kunnen ze dan met een keylogger sniffen of desnoods bruteforcen.

Dit is eigenlijk alleen belangrijk voor mensen die in gedeelde VMWare (hosted VPS bijvoorbeeld) omgevingen draaien met private keys op hun VM. Omdat je dan vanuit een andere VM de keys kan achterhalen.

Maar zulke keys zou ik sowieso nooit echt als veilig beschouwen omdat de hoster er ook bij kan.

[Reactie gewijzigd door GekkePrutser op 5 juli 2017 00:05]

Er is ook een pakket beschikbaar van GnuPG voor Windows; is deze dan ook kwetsbaar hiervoor? En zo ja, wanneer verschijnt de patch voor deze versie van GnuPG? Als ik namelijk op de site kijk https://www.gpg4win.org/download.html is de laatste versie van Augustus 2016.

gpg4win is een "wrapper" om de software, niet de software zelf. Het wordt wat minder vaak ge-update en is van een ander team. Als je niet kan wachten kun je hier terecht:

https://www.gnupg.org/ftp...g-w32-2.1.21_20170515.exe