Zdar,
k tomuto prispevku ma viedlo to, ze par clenov brmlabu pouziva GnuPG (typicky s enigmailom) a ze ked zmenim pocitac, tak mam problem najst verejne kluce, pokial si ich nevyexportujem z keyringu na nejakom inom kompe.
1. Majte kluc najditelny, idealne vygooglitelny podla mailu a potom podla fingerprintu
2. Na to sa hodi mat kluc publikovany napr. na user stranke brmlab wiki, vlastnu VPS, alebo keybase.io. Kluc sa da publikovat na PGP keyserver cez 'gpg --send-keys', potom to umoznuje ludom kluc importovat cez 'gpg --recv-keys'. Mat fingerprint na separatnej stranke umoznuje mat iny kanal, jak overit fingerprint.
Velmi dobry napad je mat na tej stranke https, takze to nikto nemoze jednoducho vymenit. V pripade vlastnej VPS/vlastnej domeny je dobre, ked si clovek moze overit cez whois, komu to patri.
Web-of-trust je failed concept, nefunguje to v praxi.
PGP keyservers (tych asi 6 hlavnych) si medzi sebou synchronizuju kluce, takze prakticky by malo byt jedno, z ktoreho tahate tie kluce (inak je na to parameter --keyserver).
Keybase.io umoznuje cloveku pouzit niekolko kanalov na publikaciu kluca (github, twitter, vlastny web, atd.)
V skutocnosti jeden z najtazsich problemov public key encryption je distribuovanie tych klucov spolahlivo.
3. Bez tych postupov vyssie to nuti ludi random akceptovat kluce (lebo ich nevedia "aspon +/- spolahlivo najst"), ktore niekde najdu a bolo uz par pripadov, ze pre "vysoko profilovych ludi" (napr. developerov Tor Project) niekto zverejnil svoje fake kluce. Dolezite je pri hladani pouzit a/alebo skontrolovat fingerprint, pretoze to kratke 32-bitove ID ide bruteforcovat. Sice to chvilu trva, a pre bezneho clena brmlabu by sa na to nikto neobtazoval, ale ide to.
4. Ked uz sifrujete, podpisujte. Pointa je, ze ziskat public key a zasifrovat nan dokaze kazdy. Preto vsetky dnes moderne schemy su tzv. AEAD (=authenticated encryption)
PGP/GnuPG je spravene tak, ze dokym sa sprava nerozsifruje prijemcom, tak sa neda zistit, kto ju podpisal. Viz nizsie o formatovani PGP sprav.
5. Niektore tieto vlastnosti mozem demonstrovat na ukazani, jak su formovane PGP spravy (RFC 4880). Napr viz v prilohe dump sifrovanej spravy, ktora bola podpisana, ale kvoli sifrovaniu neni videt jej podpis.
Da sa na to pouzit 'gpg --list-packets' alebo 'pgpdump -ilmp message.asc' (pgpdump je separatna utilita, nie priamo sucastou GnuPG).
Keby bol zaujem, mozem o tom spravit talk, jak to interne je implementovane.
5a. GnuPG by default nechava vidiet, na ktore kluce bola sprava sifrovana. Da sa to vypnut cez '--hidden-recipient' (vsetky tieto veci sa daju by default zapnut v configu ~/.gnupg/gpg.conf). Pokial ID kluca prijemcu neni urcene, GPG vyskusa vsetky private keys.
Na druhej strane ma tento option dost obmedzene prakticke pouzitie, pretoze ten, kto vam sleduje emaily, vidi odosielatela a prijemcu.
6. Nepouzivajte outdated schemy ako DSA a El-Gamal. Minimalna dlzka RSA kluca 2048 bit.
7. Co sa tyka tej poslednej zranitelnosti "E-fail" (efail.de), tak trik spociva v tom, ze je to "decrypting oracle". Niekto vam posle vas zasifrovany email a mail klienti nemaju dostatocne dobre filtrovanie na remote contect - tj. napr Thunderbird a dalsie sice filtruju remote images, ale ked pouzijete nejke zverstva s CSS, tak tam utocnik namiesa tu spravu tak, ze tam da link napr. ako CSS backgroud "https://attackes.picus/bullshit/" + zasifrovanu spravu a email klient na to spravi request. Klient spravu rozsifruje a posle request, ked cast URL je ta desifrovana sprava.
Nevedel som zatial na 100% zistit, ci nejak staci vypnut renderovanie html mailov, zatial sa to riesi. Problem je v tom, ze ti ludia nezverejnuju PoC, takze sa blbo testuje, co vlastne problem je a co ne.
7a. Na ten "decrypting oracle vulnerability" zda sa je potreba aspon v niektorych pripadoch, aby sprava mala chybu v overovani integrity (sa to vola MDC), ktory je ale zapnuty be default, takze triggernutie tej chyby neni zas tak jednoduche.
OM OM