Google gaat per augustus over op 2048bit-ssl-certificaten

Google stapt per augustus over op ssl-certificaten met 2048bit-sleutels. Ook het root-certificaat, waarmee de ssl-certificaten worden getekend, krijgt een opwaardering naar 2048bit. Voor het eind van dit jaar moet de uitrol klaar zijn.

Dat kondigt Google aan op zijn Online Security Blog. In augustus begint het bedrijf met het upgraden van de certificaten, zodat het naar eigen zeggen voldoende tijd heeft voor een zorgvuldige uitrol van de sterkere encryptie. Nu maakt Google nog gebruik van 1024bit-encryptie voor het root-certificaat.

Volgens Google zullen de meeste clients geen problemen ondervinden van de veranderingen, maar kan het gebeuren dat sommige configuraties enkele stappen moeten nemen om complicaties te voorkomen. Het gaat dan voornamelijk om clientsoftware die is ingebouwd in bepaalde telefoons, printers, settop-boxen, spelconsoles en camera's. Op zijn eigen blog legt het bedrijf uit wat er in die gevallen gedaan kan worden.

Het voordeel van de upgrade is dat het voor kwaadwillenden moeilijker wordt om de encryptie door middel van brute force te kraken. Op dit moment is het voor hackers nog praktisch onhaalbaar om de 1024-bit-encryptie op die manier te kraken, maar het is verstandig om tijdig over te gaan op sterkere encryptie om hackers voor te blijven. Hacks op de certificaatverstrekkers zelf vormen echter een groter risico, zoals eerder duidellijk werd door hacks op DigiNotar, VeriSign en Comodo.

Reacties (45)

[Soldaatje]

Kan Google dan niet 1024-bits als mogelijkheid behouden voor die apparaten die niet met 2048-bits om kunnen gaan?
Volgens die blog komt het erop neer dat alle firmware/software geupdate moet worden, zoals ik het lees, een beetje een inkoppertje. Probeer maar eens een firmware update te krijgen voor je 5 jaar oude printer, of andere oude hardware.
Straks kunnen die apparaten alleen nog onversleuteld verbinding maken of helemaal niet meer.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 05:31]

[Mr_gadget]

Gevaar is ook dat je dan misschien met een trucje 1024 bits kan afdwingen om de communicatie makkelijker te onderscheppen.

Vraag me af wat voor apparaten met Google zouden moeten verbinden, voor telefoons kan ik me het voorstellen. En daar kan je dan een custom rom opzetten die het wel ondersteunt. Maar andere apparaten? Cloud printers ofzo?
Maar het is wel vervelend als een nog functioneel apparaat belemmert wordt door gebrek aan firmware updates.

[DexterDee]

Ik weet niet of je het serieus bedoelde, maar Google heeft inderdaad een Cloud Printer dienst. Mijn Samsung laserprinter heeft ondersteuning hiervoor in de firmware zitten. Het apparaat verbindt via het LAN naar de service van Google, waardoor ik waar dan ook ter wereld een afdruk thuis uit de printer kan laten rollen. Ik kan me helemaal voorstellen dat de verbinding tussen de printer en Google via HTTPS verloopt. En dat maakt dit nieuwsbericht ineens vrij relevant

[viperthepala]

het apart aanbieden van deze certificaten op twee manieren crieert een klein probleem, zorg ervoor dat je er uit ziet als een van de systemen die compatibiliteit op 1024 nodig zijn en viola de brute-force kan nog steeds op de 1024 bit variant uitgevoerd worden.

deze invoer moet dus wel op alle apparaten uitgevoerd worden anders heeft deze geen nut.

[SuperDre]

Juist, ik vraag me dan ook af hoe het zal zijn met de googlesoftware van oudere android telefoons/tablets die geen update meer krijgen..

[Manu_]

Er is helemaal geen probleem. Volgens mij is er wat verwarring omdat het een root certificate wordt genoemd, maar Google is geen root CA. Elke keer als een apparaat een verbinding met Google wilt maken krijgt hij dus Googles certificaat (of certificate chain), dat getekend is door een root CA. Het apparaat moet de root CA kennen, en kan dan zonder enig probleem Google's certificaat controleren.

Waar het mis gaat (en wat op die blog beschreven wordt) is dat als je brakke software hebt waarin het certificaat hardcoded zit, er natuurlijk wel iets misgaat bij een verandering van certificaat. Dit zou echter nooit voor moeten komen.

[johnkeates]

Die zijn aan het eind van hun lifecycle en worden niet meer ondersteund. Dit is dan ook een goed voorbeeld van wanneer je MOET upgraden. Als je software gebruikt die met de buitenwereld communiceert, dan kan je er van uit gaan dat je op een bepaald punt aan zal komen waarbij je eigen software niet ondersteund wordt, en als er geen andere software voor je hardware is dan moet je dus upgraden om weer met 'de rest' te kunnen communiceren.

[Reactie gewijzigd door johnkeates op 23 juli 2024 05:31]

[ro8in]

Dus je moet een compleet goed werkend en functionerend apparaat maar weg gooien omdat hij het 2048 certificaat van Google niet ondersteund, terwijl de 1024 bit variant ook nog prima voldoet.

Jij bent zeker niet bepaald met het milleu bezig?

[dasiro]

milieu is niet het belangrijkste, maar wel dat functionaliteit wordt afgenomen en mensen nog maar 1 of 2 jaar geleden soms handenvol geld hebben uitgegeven aan apparaten die dan zelfs niet meer 2e hands kunnen worden doorverkocht

[ShaiNe]

Je bent ofwel onwetend, ofwel naief.

Misschien kan dit je ogen openen: "Vranckx: ons vuil in Afrika"

[hardwareaddict]

Plastic wordt helemaal niet gerecycled - plastic wordt verbrand.

De zeldzame metalen die erin zitten (die metalen zijn niet zeldzaam maar zo heten ze), die worden niet gerecycled en dus belandt dat op de schroothoop.

Je 95% is dus een wassen neus.

0%.

[Verwijderd]

Dat plastics niet gerecycleerd worden is 100% onwaar.
Vooral plastics uit wagens en afgedankte elektronische apparaten zijn perfect recycleerbaar.

[SuperDre]

waarom dan? het werkt toch nog goed? meeste van de nieuwe software is niet eens een echte toegevoegde waarde, maar is alleen maar wat kleine veranderingen zodat er weer opnieuw geld gevraagd kan worden..

[svennd]

Ik begrijp niet wat een 5 jaar oude printer naar google moet sturen; of wat een hedendaagse ... en al zeker niet over https. Hardware die op externe dienst steunt weet dat dit komt;

[Zer0]

Routeplanning met Google Maps is een voorbeeld van gebruik van Google diensten door printers, en mijn voorkeur gaat dan uit naar https ivm privacy.

[musiman]

@Soldaatje
De ketting is zo sterk als de zwakste schakel...

[wouter.N]

32317006071311007300714876688669951960444102669715484032130345427524655138867890893197201411522913463688717960921898019494119559150490921095088152386448283120630877367300996091750197750389652106796057638384067568276792218642619756161838094338476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656 mogelijkheden, maar dit betekend nog niet dat in de toekomst een computer het niet kan uitrekenen.

[deadinspace]

323 ... 656 mogelijkheden, maar dit betekend nog niet dat in de toekomst een computer het niet kan uitrekenen.

Jawel, dat betekent dat wel. Er gaat nooit een computer komen die alle mogelijkheden af kan gaan (dwz, brute-force). Daarvoor is 2²⁰⁴⁸ simpelweg te groot.

Bij zulke grote getallen werkt de menselijke intuïtie niet goed meer, waardoor mensen snel zicht verliezen op hoe groot dergelijke getallen nou eigenlijk zijn. De grootste getallen die de meeste mensen nog aardig bevatten zijn geldbedragen. De meeste mensen hebben intuitief een goed beeld van hoeveel bijvoorbeeld 100 of 1000 euro is. 20 000 euro (een gemiddeld jaarsalaris) en 250 000 (modale gezinskoopwoning) spreken ook nog enigszins tot de verbeelding. 10 miljoen euro is al een probleem; we kunnen er mee berekenen dat iemand met dat bedrag zijn leven lang niet meer hoeft te werken als hij/zij dat niet wil, maar echt begrijpen hoeveel dat is lukt toch niet helemaal. Bij een miljard zijn de meesten die mogelijkheid helemaal kwijt.

Laten we dus eens gaan rekenen met een miljard als maatstaf voor "onbegrijpbaar veel"...

Stel he, er zijn een miljard dimensies.
En elk van die dimensies bevat een miljard universums,
met in elk universum een miljard sterrenstelselclusters,
en in elk sterrenstelselcluster een miljard sterrenstelsels,
in elk sterernstelsel een miljard zonnestelsels,
in elk zonnestelsel een miljard planeten,
rondom elke planeet een miljard manen,
op elke maan een miljard werelddelen,
in elk werelddeel een miljard landen,
in elk land een miljard provincies,
in elke provincie een miljard steden,
in elke stad een miljard wijken,
in elke wijk een miljard straten,
in elke straat een miljard huizen,
in elk huis een miljard bewoners,
voor elke bewoner een miljard huisdieren,
op elk huisdier een miljard vlooien,
en ieder van die vlooien heeft een miljard computerclusters,
waar elk computercluster bestaat uit een miljard computers,
in elke computer een miljard processor cores,
waarvan elke core een miljard berekeningen per seconde kan doen (ha, die is realistisch!),
en die laten we dan elk een miljard seconden rekenen,
hoeveel berekeningen hebben we dan gedaan?

Is dat hoe groot 2²⁰⁴⁸ is? Nee, dat is pas 2⁶⁵⁸. Voor 2²⁰⁴⁸ had die lijst nog drie keer zo lang moeten zijn, maar zoveel inspiratie had ik helaas niet. Dat is hoe enorm dit soort getallen zijn...

Maargoed, tot zover intuitie.

Het is ook prima wetenschappelijk te onderbouwen dat zoveel mogelijkheden nooit nagerekend kunnen worden (tenzij we de plank ernstig misslaan in ons huidige begrip van de natuurkunde). Voor elke berekening is een hoeveelheid energie nodig, en om de informatie te kunnen onderscheiden van achtergrondruis afkomstig uit quantumverschijnselen kun je bepalen hoeveel energie minimaal nodig is per berekening. Dit is een fundamentele limiet die niet te overschrijden is.

Er heeft ooit een artikel in Nature gestaan ([url=chrome://downloads/home/marcelm/Downloads/9908043.pdf]Ultimate physical limits to computation[/url]) welke deze grens voorrekende. In dit artikel is bepaald dat met één kg aan massa maximaal 5,4258 * 10⁵⁰ ≈ 2¹⁶⁹ berekeningen per seconde uitgevoerd kan worden. Wikipedia geeft een voorzichtige schatting van 1,53 * 10⁵³ ≈ 2¹⁷⁷ kg voor het waarneembare universum. Laten we dat met een factor 8 miljard naar boven afronden, 2²⁰⁰ kg dus.

Dat betekent dat als alles in (ruim een miljard maal) het hele universum zou rekenen met de maximale snelheid die de fysica toelaat, het 2²⁰⁴⁸ / 2¹⁶⁹ / 2²⁰⁰ = 2¹⁶⁷⁹ seconden zou duren om alle mogelijkheden van 2²⁰⁴⁸ door te rekenen. Dat is 10⁴⁹⁸ jaar. 852 228 616 210 329 638 778 458 978 963 323 529 664 647 639 842 705 865 434 957 110 334 587 146 900 021 252 022 053 546 918 487 034 332 126 395 316 848 343 756 775 974 591 540 608 952 291 144 997 421 286 338 687 526 598 075 407 256 499 861 630 210 141 568 840 174 949 375 270 710 698 446 511 786 492 538 055 685 520 717 338 423 931 242 587 444 452 766 721 494 454 311 463 024 935 656 890 402 676 106 079 343 365 183 099 530 973 117 938 663 064 316 994 075 142 659 289 203 314 398 561 560 986 758 784 908 086 640 761 620 995 892 487 661 297 000 027 596 671 289 832 874 258 484 192 544 817 581 639 846 785 167 988 029 720 703 186 096 926 571 818 219 829 413 011 783 jaar. Dat is een miljard dimensies, met in elk een miljard unversums, etc. Met andere woorden: dat lukt niet. Het universum sterft miljarden malen een warmtedood voordat dat klaar zou zijn.

En DAT is een glimps van inzicht hoeveel 2²⁰⁴⁸ nou eigenlijk is.


Overigens hoeven niet alle mogelijkheden geprobeerd te worden om een 2048-bit RSA key te breken; hoewel zo'n sleutel 2048 bits lang is, is slechts een heel erg klein deel van de 2²⁰⁴⁸ mogelijkheden geldig. Ik heb hier eerder al eens een post aan gewijd. Lang verhaal kort: een 2048-bit RSA-key biedt een cryptographic strength van om en nabij 112 bits (bron). 2¹¹² is nog steeds erg veel om door te rekenen, maar dat is op termijn in ieder geval plausibel

[Reactie gewijzigd door deadinspace op 23 juli 2024 05:31]

[Len]

Eerder:

32317006071311007300714876688669951960444102669715484032130345427524655138
86789089319720141152291346368871796092189801949411955915049092109508815238
64482831206308773673009960917501977503896521067960576383840675682767922186
42619756161838094338476170470581645852036305042887575891541065808607552399
12393038552191433338966834242068497478656456949485617603532632205807780565
93310261927084603141502585928641771167259436037184618573575983511523016459
04403697613233287231227125684710820209725157101726931323469678542580656697
93504599726835299863821552516638943733554360213543322960464531847860495214
8193555853611059596230656

[Reactie gewijzigd door Len op 23 juli 2024 05:31]

[Montaner]

Je post nu exact hetzelfde getal als wouter.N ... alleen valt dat van hem weg doordat zijn reactie om een of andere reden geen wordwrap krijgt.

[cork87]

Slimme zet van Google, vind het eigenlijk alleen meer vanzelfsprekend dan dat het nieuws is. Alle certificaat verstrekkers accepteren al een paar jaar alleen nog 2048 bit aanvragen, dus waarom nu pas overstappen.

Kan iemand uitleggen waarom het voor Google een minder groot risico is dan voor certificaat verstrekkers?

[Pink Panther]

Het probleem met de certificaatverstrekkers is dat deze gehacked worden (zoals het geval bij diginotar was) en de certificaatverstrekker gehacked is, heeft men dus toegang tot het cirtificaat zelf. Gevolg is dat de hacker zelf iets kan signen als zijnde dat het afkomstig is van in dit geval google.
Het certificaat is dan weliswaar niet gehacked, maar toch blijft het effect hetzelfde.

[hiostu]

Alle certificaat verstrekkers accepteren al een paar jaar alleen nog 2048 bit aanvragen, dus waarom nu pas overstappen.

Ik kan nog gewoon 128bit en 256bit SSL certificaten aanvragen bij bijvoorbeeld Symantec/Verisign.

[deadinspace]

hiostu schreef:

Ik kan nog gewoon 128bit en 256bit SSL certificaten aanvragen bij bijvoorbeeld Symantec/Verisign.

Nee, dat kun je niet.

De "bitheid" van een public-key certificaat slaat op de lengte van de gebruikte public key. X.509 certificaten (dat zijn de certificaten die je van een CA krijgt) zijn typisch RSA, soms DSA. 256-bit RSA en DSA zijn nutteloos in termen van veiligheid, laat staan 128-bit. Beiden hebben überhaupt nooit bestaan voorzover ik weet. Tegenwoordig is RSA-1024 toch echt het gangbare minimum, en ik zou RSA-2048 aanraden.

In de context "SSL" is de verbinding typisch versleuteld met AES versleuteld, welke onder andere key sizes van 128 en 256 bit ondersteunt. Ik vermoed dat je daar mee in de war bent. Maar de gebruikte versleuteling van de verbinding heeft totaal niets te maken met het certificaat. De key-lengtes van RSA en AES zijn overigens totaal onvergelijkbaar; AES-256 is moeilijker te kraken dan RSA-4096. (daarom is het ook altijd bijzonder vermoeiend als mensen over X-bit encryptie spreken zonder de gebruikte cipher te noemen).

Mee_ schreef:

Het gaat hier over het tekenen van de certificaten (van 1024 naar 2048 bits), niet over hoe de SSL-verbinding op zich wordt versleuteld; dit is momenteel 128 bits SHA1.
Die 128- en 256 bit bij bv Verisign duidt ook op de manier waarop het verkeer wordt versleuteld, niet op de versleuteling van het certificaat

Om te beginnen is een SHA-1 een hash-functie, geen encryption cipher, en kan dus als zodanig niet gebruikt worden om een verbinding mee te versleutelen, en om verder te gaan is SHA-1 160 bits (niet langer, niet korter). Ik denk dat je in de war bent met AES.

Verder heb je wel gelijk dat SSL/TLS verbindingen typisch AES gebruiken, maar welke key strength (en überhaupt welke cipher) hangt af van wat de client en server onderling onderhandelen. De meeste https connecties die ik zie zijn 256-bit AES, niet 128-bit.

[Mee_]

Het gaat hier over het tekenen van de certificaten (van 1024 naar 2048 bits), niet over hoe de SSL-verbinding op zich wordt versleuteld; dit is momenteel 128 bits SHA1.
Die 128- en 256 bit bij bv Verisign duidt ook op de manier waarop het verkeer wordt versleuteld, niet op de versleuteling van het certificaat.

[watercoolertje]

Kan iemand uitleggen waarom het voor Google een minder groot risico is dan voor certificaat verstrekkers?

Die vraag klopt niet, die certificaat verstrekkers zijn juist een groter risico voor Google niet dan Google

Als de certificaat leverancier van Google dus gehackt wordt hebben hackers het root certificaat van Google, die kans is veel groter dan dat een 2048 bits certificaat van Google zelf gehacked wordt...

[Reactie gewijzigd door watercoolertje op 23 juli 2024 05:31]

[Snake]

Hoe zit dit met oudere Android versies? Krijgen zij toch een update? Lijkt me niet.

Hoe worden daar de nieuwe root certs gepushed?

[Hasosoft]

Hoe zit dit met oudere Android versies? Krijgen zij toch een update? Lijkt me niet.

Hoe worden daar de nieuwe root certs gepushed?

Gekeken naar de usage share http://en.wikipedia.org/w...share_of_Android_versions van Android is dat niet echt een probleem.

Volgens mij support alles vanaf 2.3.x 2048 bit ssl, en als je daar nog onder zit dan lijkt me dat je eigen probleem.

Hoe google hun certs aanpast weten ze waarschijnlijk zelf wel. Lijkt me dat ze dat prima via een update van de Google apps kunnen doen.

[Cave_Boy]

Hier ben ik ook wel benieuwd naar. Vind zo een twee drie niet echt informatie hierover.

Al is het wel dat oudere devices ook vaak een stukje trager zijn en dan ook nog een grotere sleutel is ook weer een extra vertraging...

Men koopt sneller een nieuw device ---> Goed voor de Economie

[Reactie gewijzigd door Cave_Boy op 23 juli 2024 05:31]

[Verwijderd]

1024 bit voor RSA kan echt niet meer, Google is al laat. Ook geen laffe encryptie blijven ondersteunen voor oude devices, dan maar geen internet bankieren.

In het artikel staat praktisch onhaalbaar, ik weet niet of iedereen hetzelfde durf te beweren voor 1024 RSA.

Jammer dat ze het niet meteen naar 4096 bit gaan.

[Verwijderd]

Nou, ik durf zeker te beweren dat het momenteel praktisch onhaalbaar is 1024-bit RSA te kraken. En zeer waarschijnlijk over 20 jaar nog steeds.

De asymmetrische encryptie die gebruikt wordt voor SSL/TLS is één van de sterkere schakels in het systeem. Het is vrij zinloos je daarop te richten, terwijl er al effectieve aanvallen bestaan op de cryptografie in het protocol die in de praktijk zijn gedemonstreerd (en dan heb ik het nog niet eens over het hacken van een CA of het uithalen van interface-trucs om gebruikers te laten denken dat ze veilig verbonden zijn met partij X terwijl ze eigenlijk met partij Y praten, terwijl het protocol precies doet wat het moet doen).

Wanneer bijvoorbeeld de CBC mode of operation wordt gebruikt voor de symmetrische encryptie, zijn bijna alle SSL en TLS implementaties vatbaar voor padding oracle attacks, waarmee je versleutelde data kunt decrypten door een hoop requests met gekozen ciphertekst te sturen (gemiddeld 128 per byte, wat in veel gevallen prima uitvoerbaar is om bijvoorbeeld sessie-identifiers en creditcardnummers mee te onderscheppen).

Daarnaast zijn er timing-gebaseerde side-channel attacks op de meeste populaire AES-implementaties bekend (alhoewel deze vrij lastig uitvoerbaar zijn, maar lang niet zo lastig als het ontbinden van 1024-bits priemgetallen), en het zou me niets verbazen als iemand nog een andere side-channel in implementaties van het protocol of de cryptografie daarin vindt.

Als je je beschermt hebt tegen alle bekende side-channel attacks en je nog steeds paranoïde bent zou ik er nog steeds meer waarde aan hechten dat het gebruikte hashingalgoritme up-to-date is (bijv. SHA-256 i.p.v SHA-1) dan dat er 2056-bit RSA-sleutels worden gebruikt. SHA-1 begint steeds meer theoretische deuken op te lopen, net als indertijd MD-5 (ondertussen kunnen certificaten waarvoor MD-5 is gebruikt met wat moeite vervalst worden, wat in het wild al is toegepast voor de verpreiding van Stuxnet).

tl;dr: er zijn veel grotere potentiele zwakken plekken in SSL/TLS dan RSA-1024.

[BezurK]

2^2048 is ∞ volgens de calculator op m'n mac Dat zijn een hoop mogelijkheden

[Verwijderd]

3.231700607131100730071487668867e+616

[tilburgs82]

tja, mac he. mac rekent bij de kassa ook altijd teveel...

[mace]

Dus Apple kan niet rekenen?

[Verwijderd]

Pfff, weten we nog hoe we de log() functie werkt? Dan kun je het ook nog op een CASIO'tje rekenen

[hardwareaddict]

Helaas dat lukt niet op calc.exe hier.

Opmerking: windows vista hier met nederlandse settings gaat calculator maximaal 64 bits significant en met Amerikaanse settings dan kan ik 128 bits significant rekenen met calc.exe

[pandinus]

En een quantum-computer dan?

[ZesPak]

Mooi dat ze bijblijven, 2 kbit is al een tijdje een standaard, maar om het op grootschalig niveau te implementeren komt toch wel wat bij kijken.

Google, als internetgigant per definitie, heeft er natuurlijk alle baat bij dat de diensten veilig zijn en goed kunnen blijven draaien.