Je 1024-bit RSA modul dostatečný pro DNSSEC ZSK klíče?
V lednu 2012 jsme se v opendnssec-user mailing-listu dohadovali, zda je 1024-bitový RSA modul dostatečně velký pro DNSSEC ZSK klíče. Argumentace byla založena na velikostech klíčů doporučovaných od ECRYPT v jejich kompendiu Yearly Report on Algorithms and Keysizes (2011) již je dostupné i kompendium za rok 2012.
Prý jsme naše odhady založili na příliš pesimistických odhadech Arjena Lenstry. Jediné rozumné doporučení bylo od Jakoba Schlytera, který navrhoval použít ECDSA místo RSA, protože zde se odhady dělají lépe. S nasazením ECDSA je ale spojena jedna nepříliš příjemná záležitost: určité optimalizace výpočtů nad eliptickými křivkami jsou patentovány. Z toho důvodu není v mnoha distribucích (např. RHEL, Debian) podpora ECDSA v openssl zapnuta, tudíž bez manuální rekompilace openssl nelze ECDSA zapnout ani v ldns nebo unbound. A nevypadá to, že by se to v dohledné době změnilo.
Na potvrzení, že 1024-bit RSA modulus už dostatečně velký není, nebylo třeba až tak dlouho čekat (pokud někomu nestačila práce lidí z ECRYPT). Trio Heninger, Lange, Bernstein předvedlo na 29C3 celkem jasně, že pro operátora botnetu není faktorizace 1024-bit RSA modulu zásadní problém, i když by to zřejmě znamenalo, že by se botnet prozradil (díky velké spotřebě energie a hluku větráčků na zombiích).
Standardizace kryptografických primitiv a protokolů
Rozhodnutí standardizovat Keccak jako SHA-3 přineslo dost velké rozčarování nad stavem rozhodovacích procesů v NIST. Především díky faktu, že byl vybraný kandidát, který neodpovídal zadání. Bruce Schneier se vyjádřil v tom smyslu, že by bylo lepší, kdyby NIST nevybral žádného kandidáta. Vlastimil Klíma to shrnul takto (viz Cryptoworld 11–12/2012):
NIST požadoval, aby nový tank byl rychlejší i bezpečnější než stávající. […] Po výběru vítěze vydal NIST závěrečnou zprávu, kde svůj výběr zdůvodnil. Z ní se dozvídáme, že Keccak není ani nejrychlejší, ani nejmenší (vyjádřeno „plochou křemíku“), ale má nejlepší poměr rychlosti k ploše křemíku. U našeho příměru s tankem by soutěž vyhrál tank, který není ani nejrychlejší, ani nejlevnější, ale který má nejlepší poměr rychlosti ku hmotnosti.
Nicolas Curtois, autor velmi zajímavé přednášky Security Evaluation of Russian GOST Cipher, mi k tomu řekl, že celá SHA-3 soutěž přinesla jen vyhozené peníze a že výběr algoritmu Keccak leda tak zajistí kryptoanalytikům další práci – bude o čem psát publikace. Podobně se Nicolas vyjádřil i k otázce, proč se víc nevyužívají primitiva, která jsou v určitém modelu „provably secure“, nebo je za nimi alespoň nějaký náznak důkazu. Třeba algoritmy RSA, DSA a ECDSA jsou založeny na těžkých matematických problémech; o symetrických šifrách to až na výjimky říct nelze.
Za výběrem šifer je podle Nicolase ze značné části politika. Dokonce se prý roznáší (snad pod tlakem NSA?), že „stream ciphers are not sexy“ (poslední část v uvozovkách je doslovná citace). Tudíž opět příliš mnoho FUD a politiky na úkor skutečné kryptografie. Musím říct, že osobně jsem určitý tlak proti proudovým šifrám nebo proudovým módům blokových šifer moc nezaznamenal. Což ale neznamená, že není.
Paradoxně mám pocit, že RC4 se příliš prosazuje, a to kvůli poměrně nepraktickému útoku na SSL/TLS: BEAST (TLS 1.1+ a AES-GCM zatím nejde použít kvůli nízké podpoře v serverových aplikacích). I v Qualys Labs jsou trochu přehnaně vysazeni na BEAST. A to má RC4 mnoho teoretických slabin, které se příliš neprojevují v TLS. Až na speciální případy, jako je například použití klíče na velmi dlouhý stream, třeba download obrazu instalačního DVD. Dokonce sám Adam Langley začal nedávno brojit proti CBC módu. ECRYPT s ním ve výše zmíněném kompendiu za rok 2012 nesouhlasí (viz tabulka straně 101 nebo 89 – podle papírového číslování stránek). Stejně tak zcela nedoporučuje RC4. Na škodlivosti schématu „MAC-then-encrypt“ se ale shodnou. Nicméně je pravda, že CBC lze snadno použít spatně.
Jedna z lepších zpráv je, že autor šifrovacího módu OCB v lednu 2013 celkem slevil z patentových nároků kladených na OCB. Ve zkratce je nyní možné OCB mód použít v softwaru na open source a nevojenské použití (detaily viz text licence). Pokud přemýšlíte, na co je OCB mód dobrý, vtipně to vysvětluje přehledný článek o symetrických šifrovacích módech Matthewa Greena. Zde se ukazuje, že je velmi těžké udělat licenci jednoduchou, dostatečně permisivní, ale zároveň odolnou proti povolení něčeho, co autor povolit nechce.
IETF TLS WG za poslední rok vyprodukovala několik vylepšení TLS protokolu, většinou jsou definovány jako TLS extensions, např.: TLS-out-of-band-pubkey, multi-ocsp-stapling. Myslím si, že žádný zatím nedošel do fáze finálního RFC. Nezávidím ale lidem, kteří je budou implementovat, i existující rozšíření mezi TLS 1.0 a TLS 1.2 v některých částech změnila sémantiku (třeba Server Name Indication v kombinaci s SSL session ID).
Standardizace JavaScript cryptography API a kryptografie ve webových aplikacích vůbec
Pro JS cryptoAPI jsem si vyhradil samostatnou kapitolu, protože je velmi kontroverzní. Nejpodstatnější důvod je, že všechny útoky, které se relativně podařilo odstranit z TLS a různých frameworků, se objeví znovu.
Jádro návrhu JS cryptoAPI je možné vidět v přednášce Re-igniting the Crypto Wars on the Web. Je to zvláštní přednáška (diplomaticky řečeno). Řečník sám byl dokonce několikrát napomínán organizátory i lidmi z publika, aby odpověděl na otázky a nevyhýbal se tématu. Last call k draftu je tuším 25. ledna 2013. Děsím se dne, kdy se to začne masově používat.
Několik postřehů a citací z přednášky o JS cryptoAPI:
- návrh jde proti výtkám Schneiera a Matasano Security, což je obecně špatně
- „‚Has this particular JS crypto method been overridden?‘ [… is ] outside of scope of this API“ – nelze zjistit, jestli nějaká kryptografická metoda byla předefinována a zda je to mimo plánovaný rozsah API
- „Do you really want to do this?“ – má existovat dialog, kde uživatel odklikne „OK“ na extrakci privátního klíče – už vidím tu armádu klikačů OK
- „we have collectively failed to get cryptography to the hands of ordinary users“ – protože dostat všude rozbitou a děravou variantu je mnohem lepší nápad
- API vypadá, jako když se selektivně vybere všechno, co je na OpenSSL API špatně, a udělá se z toho nové API, např. deklarace veřejného RSA exponent 65537 se zapisuje jako publicExponent: new UintArray([0×01, 0×00, 0×01]) – celkově se moc míchá X.509 s JSON
- přednášející charakterizuje API jako „messy, but very straightforward“ – krásný příklad oxymoronu
- PolyCrypt – je to polyfill implementující JS cryptoAPI. V demu PolyCryptu se z nějakého záhadného důvodu tahá skript přes obyčejné http bez TLS. Grant od Department of Homeland Security je jenom taková třešnička na dortu.
- podporuje staré a prolomené algoritmy a schémata, prý „kvůli zpětné kompatibilitě“
S mírnou hyperbolou lze situaci shrnout: „Now if Netscape had not been so chronically mismanaged as to only allow Paul two weeks to review the spec and to only give Knight 10 days to write Javascript, well the history of Web Security might have been rather different.“
Proč je současný model CA průmyslu daleko od ideálu?
O problému s Turktrustem toho bylo napsáno mnoho, nicméně je jasné, že někdo musel vědomě CheckPoint nakonfigurovat na použití MitM certifikátu. Podobně je prozrazena Nokia MitM, která MitMování nakonec přestala dělat. K dispozici je i post-mortem přednáška o legální analýze případu DigiNotar.
Zaměříme se tedy na detaily, kterým se tolik pozornosti nedostalo. Protože je to velmi obsáhlé téma, zvolil jsem cestu několika citací s odkazy na zdroje.
CNNIC CA root v Mozille
CNNIC si nedávno obnovil kořenové certifikáty v mozillím úložišti kořenových certifikátů. Zvedlo to poměrně velkou vlnu nevole, na čemž je nejzajímavější fakt, že lidé z Číny nemohli přispívat do Google Groups, protože Čína filtruje HTTPS přístup k některým Google službám. Mimochodem u Microsoftu to není lepší, do jeho Root programu se dostane v zásadě každá vláda. Pár komentářů později:
Nevyjádření souhlasu v krátké době je považováno za souhlas: What I have also seen was post-hoc debate about the inclusion of the Chinese CA CNNIC (CN-NIC), which IMO highlighted a shortcoming of the process: If participants do not have much time, the one-week discussion period may pass without many comments and a CA thus be included. In the case of CNNIC, many objections were raised afterwards as this CA had been allegedly associated with malware in the past; there was also concern the Chinese government might use it to issue the kind of MITM certificates we're worried about. No proof of any such activity could be given, and Mozilla decided that the fair approach was to keep them in.
Řešení Jeffrey-ho Walton-a: I mark those certificates as untrusted. I was born at night, but not last night.
Kolik stojí rozběhnutí kořenové CA
Neskutečně dlouhá, ale o to výživnější debata o tom, co všechno je potřeba na rozběhnutí kořenové CA. Nebudu napínat, spodní odhad je asi milion dolarů, z toho se nejvíc spotřebuje na protlačení se do kořenových úložišť různých browserů; na hardware z toho připadá přibližně 250 tisíc USD. Základem je dostat se do úložiště certifikátů Microsoftu, pak je údajně cesta mnohem snazší. Pár klíčových pozorování, místy i cynicky vtipných (někdy bude nutné přečíst i kousek odkazu pro lepší pochopení kontextu):
Účinnosti auditů CA: As a matter of my experience, the audits and auditors generally turn a blind eye to user interests, and generally concentrate on those things that the CAs think is important to them. […] Auditors don't care as long as they are respected and they get paid their fees. Everyone's happy.
So what is the real question? This is mine: does the audit do anything positive for the users? My answer – no.
Kartely v CA biznisu: Sadly, of course, there are far too few economists and business people in the area of cryptography and PKI, so talking about the economic theory of cartels and so forth is wasted. The normal response will be for the supporters to chime in, shout the economists down, insist they prove their points, and drown out the dissent.
Vědeli jste, že společnost PGP chtěla spustit vlastní CA? I code-named the project Casablanca. Partially because Casablanca begins and ends with a CA, but mostly because I really like the phrase, „I am shocked, shocked that PGP is issuing X.509 certificates.“
Kritika reakce Mozilly na MitM certifikát od Trustwave: Everything Trustwave and Mozilla did [publicly] was likely a dog and pony show to alter our perception of reality.
Myšlenka Convergence jde proti implementaci Convergence: A funny thing: when I tried Convergence, it made the certificates look like they were all signed by Convergence. It broke Certificate Patrols' validation. So I deleted Convergence. There I exercised my Trust Agility, just what Marlinspike promotes. :-)
CA nemůže ani při nejlepší vůli bojovat proti phishingu, nezávisle na tom, co tvrdí její markeťáci: Phishing is not something that PKI is intended to address.
Banky často ani samy nevědí, komu a jak outsourcují, a které URL nejsou phishingové: I love this – everyone has a story about how their bank is just totally hopeless. […] Whatever this domain was, I did the traceroute and whois and found that the whole thing was a totally independent outsourced organisation outside CBA's country. As it turns out, it was outsourced to HP's cloud operation in California. On the same day, I read an article in the major newspaper from the IT director of the bank saying they would never ever outsource customers' data outside the bank.
Na závěr, cena za nejinovativnější ad hominem přísluší výroku: „Thank you, Strawman McBogusArg!“
