viacces 2 BF

22 december 2002

Voor info over DES algoritmes en encryptie in het algemeen kan ik je de volgende URL's aanraden:

Handbook of Applied Cryptography:

http://www.cacr.math.uwaterloo.ca/hac/

The DES algorithm illustrated:

http://www.aci.net/kalliste/des.htm

Cryptography FAQ:

http://www.faqs.org/faqs/cryptography-faq/

Ook door met Google te zoeken naar documentatie op universiteiten (.edu) kan je heel veel mooie informatie vinden.

Als je liever een papieren uitvoering hebt dan kan ik je het boek "Applied Cryptography" van Bruce Schneier aanraden. Van al het materiaal dat ik tot nu toe heb gelezen leest deze nog het 'makkelijkst' weg, daarnaast is Bruce Schneier een bekend figuur in de crypto-wereld en hij weet dus absoluut waar 'ie over praat.

Laatste update over de 16-byte VIA2 key: het lijkt erop dat het een soort 'per-ongeluk-publieke-test' is geweest. Deze key was nl. kennelijk geadresseerd aan slechts 1 (!) kaart...

Vermoedens zijn dan ook dat het een vergissing is geweest (a la Deepam - die een keyupdate sturen, alleen vervolgens dezelfde key meesturen... ).

Feit blijft natuurlijk wel dat dit soort keys dus nu wel een bepaalde betekenis hebben...zolang er nog geen nieuwe nano's gelogged worden is de impact hiervan nog onduidelijk. Voorlopig gaat de Bruteforce ook gewoon op de oude manier door.

realist · 28 december 2002

Verschillende topics gelezen over het Via 2 BF projekt, en ook de faq "The DES Algoritm" van Orlin Grabbe doorgeworsteld. (Dit was tenminste een goeie).

Nu ga ik een paar vragen stellen (opmerkingen maken) in dit forum in de hoop dat ze niet misplaatst zijn.

1) Gelezen:"Viaccess licenties zijn er in verschillende vormen en blijkbaar ook in een vorm waarin de provider alleen maar een 08-key heeft en niet de mogelijkheid om deze middels een EMM bij te werken. Hopelijk geldt dit ook voor VIA2."

Mijn vraag:

Een provider wil versleutelen en heeft dan blijkbaar de keus uit een aantal algoritmes, die qua mogelijkheden verschillend zijn. Wie exploiteert hier algoritmes? en hoe is dan de betaling geregeld.?

Is het ook bekend hoeveel consistente algoritmes er in omloop zijn en dan speciaal voor versleuteling van TV-programma's?

2). Als je beschikt over gecodeerde en gedecodeerde paren" CW"s en je hebt de Key, proberen krakers dan ook om het algoritme te ontleden? Of worden deze gewoon public gemaakt?

3)Ik zou graag willen weten wat nu die "bugs" inhouden, die zich voordeden waardoor je Viaccess 1 kaarten wel uit kon lezen .

4) Is Algor. Viaccess 1en 2 hetzelfde?

Ik ben nu geneigd om te denken van ja. Viaccess 1 werkt uiteindelijk met een 56-bits sleutel, omdat er 8 bits v/d 64 niet meedoen (pariteit?). Als je nu ook maar één van deze bits een functie geeft in het Viac- 1 algor., dan zal dat volgens mij een ander versleuteld CW opleveren bij een bepaalde O.Key , en het algoritme zal dan ook niet meer symmetrisch zijn, zodat je bij ontsleutelen niet weer hetzelfde CW terug krijgt.

En dan kan je dacht ik net zo goed een geheel nieuw algor. ontwikkelen.

Dus ik zou denken, dat wanneer je uitgaat van hetzelfde algo, dat je dan bij een BF ook uit zou moeten gaan van een 56-bits key. En dat scheelt een tijdsfactor van 2^8=256.

5_ wat is zo ongeveer een spin-off van het DESalgoritme?

Hopende dat antwoorden hierop voor andere lezers ook de moeite waard zijn en BVD.

Gr. V/d realist

Vl29 · 29 december 2002

ik vind het in ieder geval machtig interessant waar jullie over praten.

Hulde...

29 december 2002

1) De Viaccess encryptie voor dit soort doeleinden is een van de produkten die wordt aangeboden door Viaccess SA ( http://www.viaccess.fr ). Hoe de licenties in dit geval precies afgehandeld worden is (mij) niet bekend. Dat zijn zaken waar allemaal NDA's (Non Disclosure Agreements) voor getekend moeten worden.

Wat ik in de praktijk ken (ik werk dan wel in de IT en niet in de sat.wereld, maar ook daar komt je dit soort zaken uiteraard ook tegen) is dat men meestal een jaarlijks bedrag betaalt en hiervoor een soort 'Black Box' kastje krijgt waarvan je alleen te horen krijgt hoe je 'em aan moet sluiten. De feitelijke werking wordt compleet voor je geheim gehouden. (Natuurlijk om de integriteit van de encryptie te bewaren. Stel dat er een provider failliet gaat en de gegevens in verkeerde handen vallen).

Of er nog meer algoritmes verkrijgbaar zijn buiten de algemeen bekende zoals die hier op dit board behandeld worden weet ik niet. Ik ken er zo in ieder geval niet meer. Ga er maar wel van uit dat er vele in ontwikkeling zijn, vooral voor wanneer encryptie over kabelnetwerken gemeengoed wordt. Dit is nl. een gigantisch afzetgebied en maakt de markt zo ont-zet-tend veel groter.

2) Nee, met alleen deze gegevens kan je nl. weinig tot niets. Het enige wat je hiermee kan is verifieren of het algoritme -dat je op een andere manier uitgedokterd hebt- klopt.

Hier even een stukje dat ik een keer in het Seca2-forum gepost heb:

Citaat:

Wat gebeurt er feitelijk tijdens een bruteforce? Je hebt 2 gegevens - een gecodeerd en een gedecodeerd deel. Deze delen zijn mbv. van een officiele kaart van de stream van een provider achterhaald en hebben middels een bepaalde algoritme (+de key) een verband.

Door alle mogelijke combinaties los te laten op het algoritme kun je de missende key vinden. Deze key kan je dus gebruiken om het gecodeerde deel met behulp van het algoritme om te zetten naar een ongecodeerd deel.

Wanneer de key gevonden is wordt deze vervolgens getest op andere setjes gecodeerde/gedecodeerde delen. Als je deze allemaal (correct) kan omzetten dan is dat het bewijs dat het algoritme juist is en dat je juiste key hebt.

Iets wat soms moeilijk te bevatten is: je vindt altijd een key tijdens de bruteforce, maar het verband (het algoritme) hoeft niet juist te zijn!

Simpel voorbeeld:

gecodeerd: 16

gedecodeerd: 7

Vermoeden wat je hebt dat het algoritme zal zijn: 'delen door Key K - 1'.

"Door alle mogelijkheden te proberen" <img src="/ubbthreads/images/graemlins/wink.gif" alt="" /> kom je erachter dat op basis van dit algoritme Key K de waarde '2' heeft.

Maaarrrrr, nou vertel ik je dat het algoritme eigenlijk vermenigvuldigen met key K - 41 blijkt te zijn! Dan blijkt de (juiste) key opeens '3' te zijn!

En wat als je denkt dat het algoritme 'Vermenigvuldigen met K - 25' is...dan heb je ook een Key die '2' is...

Zels als je de correcte key hebt kan je hier nog niets mee....stel ik geef je de waarde '3' - wat in dit voorbeeld de juiste key is - en je moet voor mij de waarde 17 decoderen. Hoe ga je dat doen??

Oftewel: je kan een algoritme hebben waarvan je denkt dat het de juiste is - je kan de bijbehorende key daarvoor bruteforcen, maar als je vervolgens alleen die ene set gecodeerde/gedecodeerde delen kan omzetten heb je nog niets want je moet ook weten wat er met andere setjes gecodeerde/gedecodeerde delen moet gebeuren...anders moet je alle mogelijke setjes die in de stream van een provider kunnen voorkomen bruteforcen. (vervolgens heb je een mega-Funcard8000 ofzo nodig met een complete database: 20:19, 30:49 etc...enkel omdat je de correcte antwoorden niet kan berekenen!)

Eigenlijk worden DCW's dus nooit gepubliceerd. DCW's zijn nl. maar beperkt geldig en leveren dus maar voor een beperkte tijd beeld op en zijn dus meestal nutteloos. Wat wel kan (en waar hier meen ik ook al posts over zijn geweest, was dat Rattan die daar mee bezig was?) is de zg. McCormack hack: je kan het antwoord van een kaart wel afvangen - als ik dat vervolgens snel genoeg doorstuur kan jij dat antwoord (zonder kaart) _ook_ gebruiken om beeld te krijgen. Het enige wat je hier aan kan doen is je encryptie aanpassen om zo snel te wisselen van ECW/DCW's dat dit niet meer haalbaar is.

3) Ik heb het zelf nooit geprobeerd maar een Viaccess1 kaart had een commando (bug of backdoor?) in de vorm van het "BC 52" commando. Dit commando wordt dan wel (schijnbaar) geweigerd door de kaart maar vervolgens kan je door het commando "CA B8 00 00 FF" vele malen uit te voeren (iets van 30 keer)in totaal 7 KB van de EPROM uitlezen..

In latere versie van de kaart (v2.4) bestonden nog wel commando's in de BC xx serie maar de bug zelf niet meer. De v2.6 kaarten kennen deze hele commando-reeks niet meer.

4/5) Wat ik bedoelde met een spin-off van DES is dat Viaccess in grote lijnen hetzelfde functioneert als DES maar met een paar kleine verschillen. 1 van deze verschillen is dat Viaccess _geen_ gebruik maakt van parity en dus een volledige 64-bits key verwerkt. Omdat je DES inmiddels bekeken hebt hoef ik je over S-Boxes niets meer te vertellen (voor diegene die het niet kennen: S-boxes zijn vertaaltabellen om de originele waarde zo efficient mogelijk 'door elkaar te husselen' zodat de begin en eindwaarde geen doorzichtige relatie met elkaar meer hebben), deze S-boxes zijn in VIA1 en DES gelijk. Alleen het parity verhaal ontbreekt dus in VIA en de eerste en laatste 'permutatie' is verschillend. Daarnaast maakt VIA uiteindelijk ook nog onderscheid in de even en oneven keys. De oneven keys krijgen nog een extra bewerking.

De reden waarom dit gebaseerd is op DES, is vanwege de S-Boxes: deze zitten bijzonder goed in elkaar en dat is de kracht van DES. Er bestaan hierdoor ook slechts 4 'zwakke' keys en 12 'semi-zwakke' keys. Deze leveren tijdens de berekening vergelijkbare (of dezelfde) resultaten op. Overigens zijn dit de 4 zwakke keys (in hex) mocht je hiermee willen gaan stoeien:

0000000 0000000

0000000 FFFFFFF

FFFFFFF 0000000

FFFFFFF FFFFFFF

Door deze S-boxes van DES te gebruiken bescherm je jezelf ook behoorlijk goed tegen andere soorten attacks: de "Differential Cryptanalysis" en de "Linear Cryptanalysis". Als je OF vastegestelde paren hebt (diff.crypt) OF je hebt heel veel gecodeerde/gedecodeerde paren (lin.crypt) dan kan je hier ook berekeningen op los laten om patronen te herkennen en zo een nieuw paar te bepalen. Dit is in aanvallen op DES alleen theoretisch behandeld (en als niet zinvol/praktisch beschouwd), ik ben niet bekend met een praktijkgeval. Viaccess is hier dan ook niet gevoelig voor.

Daarnaast is DES relatief snel en vanwege de de aard van de bewerkingen en 'beperkte grootte' erg geschikt (en goedkoop) te implementeren in hardware.

Dit soort eigenschappen van DES zorgt ervoor dat hier nog meer spin-off's van bestaan: MDC, MacDES etc.

Dus het idee van jou -over het geven van een functie aan een deel van de key- gaat voor VIA1 niet op. Maar het is wel leuk dat je het noemt omdat dat wel een gedachte is die vele hebben bij de inmiddels beruchte 128-bits key die ik al eerder aangehaald heb. Via2 kaarten accepteerden deze 128-bits key namelijk - maar was het ook echt een 128-bits key? Daar zijn nu veel verschillende gedachtes over en datzelfde idee wat jij hebt komt daar ook in voor: misschien is het wel een key met daarin een commando? Goed mogelijk, maar daarover bestaat nog geen zekerheid. Omdat de impact van deze update nog niet duidelijk is, is ook niet bekend wat de kaart met deze key gedaan heeft.

Wat de meest logische stap zou zijn voor Viaccess SA _mochten_ ze gewisseld zijn van algorithme is een overstap naar 3DES. Je bent dan backwards compatible (door 2 keer dezelfde key te gebruiken) en je hebt dezelfde eigenschappen als Single-DES maar dan met een 128-bits keyspace...

(Mocht ik mensen helemaal het bos ingestuurd hebben met termen als s-boxes, permutaties e.d. dan kan ik daar -als daar behoefte aan is- nog wel een keer over uitwijden...)

edit: tikfout

realist · 1 januari 2003

@Robin

Natuurlijk allereerst bedankt:

1)Uit jouw antwoord leid ik af, dat algoritmes wel degelijk produkten zijn, waar mee geheimhouding gemoeid is en dat een algoritme niet gemakkelijk te achterhalen is.

Daarom vindt ik het zo verwonderlijk dat deze open en bloot in verschillende faq's besproken worden, maw, hoe worden deze dan bekend?

Immers! Als je de betreffende key niet kunt achterhalen is erg, maar heb je daarbij geen algoritme, dan kan je het helemaal schudden.

2a) "Iets wat soms moeilijk te bevatten is: je vindt altijd een key tijdens de bruteforce, maar het verband (het algoritme) hoeft niet juist te zijn! "

Ik weet niet precies welke eisen aan algoritmes gesteld worden, maar ik kan mij voorstellen dat je bij "block cipher" een zog. 1<-->1 afbeelding construeert tussen 64-bits blokken. (ECW en DCW)

In dat geval zou je volgens mij bij elk goed werkend algoritme ook altijd een key moeten vinden bij een volledige BF.

2b) Als ik het DES- algo doorlees, dan valt het mij op dat de verschillende "bewerkingen" (dat zijn er heel veel) ogenschijnlijk vrij willekeurig zijn. Je zou haast denken: Moet hier nu zo lang over nagedacht worden. Nu mijn gedachtengang:

Het geniale moet hem zeker zitten in het feit dat je via het algo en een key, een data block (in dit geval een64 bit DCW) versleuteld naar een 64bits ECW, en dat je daarna ,door dit algo nog een keer toe te passen op het ECW met dezelfde key weer het oorspronkelijke DCW terug krijgt.

(waarbij de volgorde v/d subkeys wel omgedraaid moet worden).

Ik ben wel nieuwsgierig of je het met deze kronkel eens kunt zijn, of anders commentaar hebt.

4/5)"Alleen het parity verhaal ontbreekt dus in VIA en de eerste en laatste 'permutatie' is verschillend."

a)Als ik mij realiseer wat er tijdens al die bewerkingen met de "arme" bitjes gebeurt, dan kan ik mij niet voorstellen dat er niet een contrôle systeem moet zijn om fouten te voorkomen., maar dat valt een beetje buiten het verhaal.

Dat de eerste en laatste "permutatie" verschillend is, gaat mij helaas boven de p*t.

c) Overigens zijn dit de 4 zwakke keys (in hex) mocht je hiermee willen gaan stoeien.

Ik zou dat wel willen, maar hoe? . Ik ben wel eens een programma tegen gekomen, waarmee je bepaalde commando's kon nabootsen ( ik denk bijv. aan "Mac talk" voor seca commando's)

Is er ook zo iets voor een algoritme? Het zou in ieder geval leerzaam zijn.

Met de beste wensen voor het nieuwe jaar, en de Gr. V/d realist

realist · 1 januari 2003