Cryptografieprofessor: hoogste tijd dat PGP verdwijnt
De bekende cryptografieprofessor Matthew Green, die onder andere betrokken is bij de audit van het encryptieprogramma TrueCrypt, heeft een betoog online gezet waarin hij pleit voor het verdwijnen van Pretty Good Privacy (PGP). PGP wordt onder andere gebruikt voor het versleutelen van e-mail.
Onlangs kondigden zowel Google als Yahoo aan dat ze e-mail met behulp van PGP gaan versleutelen. Green benadrukt dat dit een positief effect op het gebruik van versleutelde e-mail zal hebben, iets wat hard nodig. Toch is PGP niet het antwoord, aldus de professor. "Het probleem is dat ondanks al het goeds PGP in het verleden heeft gedaan, het een e-mailencryptiemodel is dat fundamenteel stuk is. Het is tijd dat PGP sterft."
Sleutels
Het eerste kritiekpunt is het gebruik van sleutels. PGP werkt met een privésleutel en een publieke sleutel. De sleutels zijn zo lang dat ze niet handmatig door mensen zijn te controleren. Mensen moeten echter wel de authenticiteit van een sleutel verifiëren, wat via sleutelservers en 'public key fingerprints' wordt gedaan. Het opvragen van een publieke sleutel aan de hand van een fingerprint gebeurt in het geval van GnuPG via HTTP. Daarnaast zorgde een bug in de één na laatste versie van GNuPG ervoor dat de fingerprint van ontvangen sleutels niet werd geverifieerd.
Het tweede kritiekpunt van Green is dat PGP geen Perfect Forward Secrecy (PFS) gebruikt, of forward secrecy zoals hij het noemt. Bij PFS wordt voor elke sessie een aparte sleutel gegenereerd en na het aflopen van de sessie of het versturen van een bericht verwijderd. In het geval aanvallers de encryptiesleutel compromitteren hebben ze nog geen toegang tot de eerder opgeslagen berichten van gebruikers, aangezien die met een aparte afgeleide sleutel zijn gegenereerd. Het gebruik van PFS binnen PGP zou wel mogelijk zijn, maar dit vereist aanpassingen aan het PGP-protocol die waarschijnlijk niet zullen plaatsvinden.
E-mailclients
Een ander punt dat Green dwarszit is de implementatie van PGP binnen e-mailclients. Daardoor kan het voorkomen dat belangrijke e-mails onversleuteld worden verstuurd en voor onbelangrijke berichten de encryptie staat ingeschakeld. Google en Yahoo lossen dit probleem op door helemaal geen gebruikersinterface te tonen, maar dit maakt encryptie weer ontransparant. Daarnaast moeten gebruikers ook de sleutelmanagementoptie van Yahoo en Google vertrouwen.
Volgens Green moet er dan ook het nodige gebeuren. Hij pleit voor een betere aanpak van het sleutelbeheer. Daarnaast moet forward secrecy in het protocol zitten ingebakken en moet er nieuwere encryptie worden gebruikt. Als laatste moet de "backwards compatibility" worden geschrapt. "Het beveiligen van zowel versleutelde als onversleuteld e-mail is te moeilijk. We hebben aparte netwerken nodig die dit vanaf het begin afhandelen."
Green erkent dat hij misschien als een zeurkous klinkt. "Maar zoals ze zeggen: een PGP-criticus is slechts een PGP-gebruiker die de software al een tijdje echt heeft gebruikt." Volgens de professor is er zoveel potentie en zijn er zoveel mogelijkheden om het op dit gebied beter te doen. "Het is tijd dat we die ideeën omarmen en stoppen met terugkijken."
Zucht. PGP is geen webserver. Heeft helemaal geen mogelijkheden voor PFS.
En wat heeft ECC (een protocol) met email encryptie te maken? Vindt je RSA niet goed genoeg, denk je dat ECC beter is? Zo ja, dan begrijp je niet wat het door Green aangestipte probleem is.
Heb ook een beetje het idee dat het hele betoog van Matthew Green rust op de Forward Secrecy. Waarvan hij zelf toegeeft dat het lastig te implementeren is in PGP.
Het ophalen van een public key, bijv. vanaf een keyserver, via http (niet https) is een risico [1], maar moet niet worden overschat. Het punt is dat iedereen public keys kan uploaden naar key servers, zonder dan hun identiteit (dus authenticiteit) wordt vastgesteld.
Een groot probleem, bij elk protocol dat je bedenkt, is dat het meestal enorm lastig is om vast te stellen of een public key daadwerkelijk toebehoort aan iemand die jij niet persoonlijk kent (d.w.z. de persoon die over de bijbehorende private key beschikt, als het goed is als enige).
Om enige zekerheid te hebben kun je via een ander kanaal vaststellen dat de ontvangen public key identiek is aan de public key van de eigenaar (bijvoorbeeld door die persoon te bellen, ervan uitgaande dat je erop kunt vertrouwen dat het telefoonnummer daadwerkelijk van de bedoelde persoon is). In de praktijk doe je dat niet door de public keys zelf met elkaar te vergelijken (veel te lang), maar door de fingerprint ervan met elkaar te vergelijken.
Verder heeft Matthew Green goede argumenten, lees http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html voordat je reageert (hij noemt o.a. alternatieven met potentie).
[1] Stel een aanvaller heeft MitM toegang tot jouw netwerkverbinding. Als jij eerst een binary met bijbehorende signature file downloadt via http (of ftp), kan de aanvaller de binary en de signature file wijzigen. Als jij vervolgens de public key ook via een http downloadt, kan de aanvaller ook die wijzigen. Als jij die key, zonder op andere wijze te controleren dat die key daadwerkelijk van de bedoelde auteur is, gebruikt om de integriteit en authenticiteit van de binary te controleren, maak je een grote fout.
Het scenario dat download van de public key vanaf een keyserver via https zou plaatsvinden helpt hier niet met 100% zekerheid. De aanvaller kan de signature file bijvoorbeeld zo wijzigen dat gesuggereerd wordt dat een andere ontwikkelaar uit het vertrouwde team de binary heeft ondertekend, waarvoor de aanvaller een public key heef geupload naar keyservers. Je moet dus altijd proberen vast te stellen dat een public key daadwerkelijk van de gesuggereerde persoon is (en dat die persoon geautoriseerd is om te signeren), en dat is meestal knap lastig als je de betreffende ondertekenaar of haar/zijn collega's niet persoonlijk wilt lastigvallen.
Toch denk ik niet dat een tiental alternatieve, "betere" systemen uitvinden nou zoveel zoden aan de dijk gaat zetten. Wat dacht je er van eerst eens in wat we hebben te duiken, dat echt te doorgronden, en daarna pas te verzinnen hoe het beter kan?
Overigens kan ik aanbevelen om het originele artikel ook te lezen.
Als de bedoeling is e-mail helemaal te vervangen. Veel succes! Maar ik geloof niet dat dat ooit zal lukken. E-mail is net zoiets als IPv4. Dat gaat nooit meer weg :-/ Compatibiliteit met PGP 2.x verdwijnt wel langzaam maar zeker omdat degene die GnuPG onderhoudt daar geen energie meer in wil stoppen (PGP 2.x werkt o.a. met MD5 en dat kan niet veranderd worden).
Als de bedoeling is e-mail helemaal te vervangen. Veel succes! Maar ik geloof niet dat dat ooit zal lukken. E-mail is net zoiets als IPv4. Dat gaat nooit meer weg :-/ Compatibiliteit met PGP 2.x verdwijnt wel langzaam maar zeker omdat degene die GnuPG onderhoudt daar geen energie meer in wil stoppen (PGP 2.x werkt o.a. met MD5 en dat kan niet veranderd worden).
Over MD5, ik weet niet of dit over hetzelfde gaat, maar de hashing methodes kan je wel via een config file aan passen:
https://www.apache.org/dev/openpgp.html#sha1
Of dat hier ook het geval is, ach, pgp/gpg heeft hele duidelijke problemen, en dit onderkennen is wel een noodzakelijke eerste stap. Wat nu verder te doen? Geen idee. Tijd voor wat brainstormen dan maar. Iemand moet het doen.
Bijvoorbeeld, PKI is problematisch omdat het van een hierarchie uitgaat, iets wat binnen een grootbedrijf nog wel zou passen (voor zekere taken) maar voor een heel land is het al nodeloos restrictief en voor heel de wereld is het een onbeveiligbare ramp. Die ~600 CA certificaten in je browser zijn 600 single points of failure.
Daarnaast is het voor DNSgebruik een volstrekt nodeloze hierarchie die geen enkele binding heeft met DNS; wat ze daar hadden moeten doen is een "natuurlijke" binding tussen hostnaam en certificaatuitgever, bijvoorbeeld uitgedeeld als gratis extraatje bovenop de domeinnaam die je bestelt. Maar zou de dood zijn van een hele commercie, en een behoorlijk lucratieve ook nog.
PGP gebruikt een web of trust dat weer een hele eigen problematiek kent, net zo goed te beginnen met dat het eigenlijk te ingewikkeld is voor non-cryptonerds om te begrijpen, laat staan te gebruiken. Wat betekent het dat je anderen vertrouwt om certificaten te introduceren? Je moet dus vertrouwen dat ze weten waar ze het over hebben, en hoe weet jij dat?
Als hypothetisch voorbeeld: Wat je zou willen is bijvoorbeeld dat je voor bestellen bij een webshop het certificaat nagaat --eentje waar meerdere signaturen op voorkomen, iets wat PKI VZIW niet kan-- en of daar een signatuur van je eigen bank tussen zit, zo van "wij geloven dat deze shop hun zaakjes op orde heeft". Je vertrouwt je bank met je geld dus is het niet raar om op hun signatuur te vertrouwen voor een webshop. Je zou zelfs wettelijk een garantieplicht aan zo'n signatuur kunnen hangen.
Maar dat wil je dan weer helemaal niet voor websites waar hele andere dan bankzaken afgehandeld worden, daar wil je signaturen van hele andere partijen vertrouwen. Dat onderscheid kan je nu helemaal niet maken. Een signatuur van de Turkse overheid is net zo goed als een signatuur van de Nederlandse, of van een willekeurig Amerikaans bedrijf. PGP heeft vergelijkbare problemen, iets wat de professor ook aanstipt.
Ik zou zo snel niet weten hoe je dat oplost, maar door het helder te maken dat daar een probleem zit kunnen we mogelijke oplossingen gaan verzinnen.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
