seca2 faq

Главная - Апрель 2005 - seca2 faq   
Nader kennis met de ECM/EMM
By Supergip vertaling door Azazel

Als eerste zou ik aan willen geven dat voor het begrijpen van deze FAQ,
allereerst kennis van zaken moet hebben betreffende het seca systeem met behulp van Seca FAQ. Alles wat hier vermeld wordt is uitsluitend bedoeld voor het onderzoek en studie van seca2.


Nieuw in het seca2 systeem

Aan de hand van een log van een ECM is het mogelijk om het eerste karakter-
eigenschap van het nieuwe systeem te realiseren:

C1 3C 01 BE 5C
10 01 CD 99 F1 E7 88 F1 E9 00 50 F9 09 5B 02 43
DD 03 35 39 1B C2 41 97 AF B3 8A A7 F7 9A FA 78
12 C9 BA 23 16 42 99 0E 9A F3 31 72 22 BC B8 C6
62 45 37 F9 7F 68 15 7C BB 7C A7 F2 3D F8 27 82
52 49 54 56 98 0C AB 94 26 95 74 A7 12 B6 83 4D
23 46 03 F1 E1 A5 66 31 05 96 46 48 [90 00]


Bij wijziging van alle bytes, behalve de rode, tussen twee verschillende ECM's, is enig nanocommando onbekend en is er geen spoor van de 'signature' te bekennen: de reden hiervoor is het simpele feit dat de data encrypted is.
Men weet nu dat er bij seca2, twee paren van ecryptie aanwezig zijn:
de SUPERENCRYPTIE (werkt met blokken van bytes) en de SECUNDAIRE SUPERENCRYPTIE (SSE of Envelope), die handelt de data die zijn geintegreerd.
Deze processen van encryptie zijn verplicht voor de data van de ins. 3C/38/40.
Het gebruikte algoritme voor de SSE is vooralsnog onbekend, al verdenkt men dat
er gebruik wordt gemaakt van een decrypt type RSA.
De superencryptie zou anders dan de SSE moeten lijken op die van SECA.



Superencryptie (SECA)

Als men de instructie in zijn geheel neemt (incl. de signature) en deze is
te delen in blokken van 8 bytes, bij elk blok kan men de algoritme van encryptie
met de key aangegeven door P2 toe passen.
Als de bytes die overblijven een nummer minder dan 8 zijn, dan kan de blok niet
compleet gemaakt worden en blijft het gecodeerd.



De structuur van de ins 38/3C/40

De klassieke formulering van SECA is compleet gehandhaafd met respect naar ISO 7816.

C1 38/3C/40 P1S P2 LEN + pakket van data

p1
Bit 0...3 :Aanduiding van de provider naar waar de commando verstuurd wordt.
Bit 4 :Gebruiken van primary key of primary + secundary key.
Bit 5,6 :Geeft begin aan van flashbuffer voor de berekening van de 'signature'
Bit 7 :niet in gebruik.

P2
Bit 0...3 :Aanduiding van de gebruikte key voor decrypten van de SuperEncryptie.
Bit 4 :Betekennis onbekend (moet zijn = 1)
Bit 5,6 :Selecteerd de map voor desencryptie en een eventuele user ALGO (niet actief bij de v7).
Bit 7 :Aanwijzer van de SuperEncryptie (moet zijn = 1)

LEN
Is de lengte van de 'pakketten van de data'

Voorbeeld:

C1 40 01 B1S 5C
10 01 12 08 F5S 56 DE F0 11 12 DOS D8 40 3B 34 7A
EB A5 B7 30 41 50 5F 02 6D B2S 03 ABS 29 2B 29 7A
05 4F AFS 83 18 75 1F 33 49 67 29 0CS C0 22 C7S 44
E3 BA 45 6D 1B 3A F3S 56 07 A9S 89 5D B4S 5E 8A D1
1F 40 F4S 50 D1S 57 D0S 96 88 5B EBS 93 2A 10 CE E8
4D 36 1F 80 A7S 65 A6S 9C 3E 03 78 49


Zoals eerder vermeld, zullen de twee bytes aangegeven in rood, voor alle lengtes van de INS zich hetzelfde handhaven.
Ze vertegenwoordigen enige parameters voor de SSE en 'gedragen' zich verschillend met respect op alle andere data. Ze geven ons de definitie aan van parameters P3 en P4.
Binnen deze data bevind zich een parameter van zeer grote extensie die niet zichtbaar is, vanwege het feit dat deze encrypted is.
Zijn funktie zal ik nader uitleggen, maar als eerste is het genoeg om
zijn extensie, zijn positie (de laatste byte van de data) en de naam (P5)
te weten. Dit wetende kunnen we een nieuwe uitvoering van de structuur
van de INS aangeven:

C1 38/3C/40 P1 P2 LEN P3 P4 + Data Pakket (P5)

Volgende deel: het proces van executie van de INS.

Saludos!

'Azazel miembro del equipo RAIDEN, la resitencia.'

--------------------
LLORAMOS JUNTOS, GANAREMOS JUNTOS!


Bericht opties

Azazel
Sat4all erelid


Lid sinds: 18/05/2002
Berichten: 317
Uit: en las montañas Re: Seca2 FAQ [Re: Azazel]
#286325 - 01/04/2003 23:41 Bewerken Antwoord Citaat Snel antwoord



Proces van executie van de ins.

In grote lijnen heeft het deze logische 'gebeurtennis' (en tijdelijk):

1 - De normale controles van protocol ISO7816 CLA/INS/LEN (mogelijke status error 6D00, 6E00, 6700)

2 - Controle van P1, aanwezigheid van de provider
(status 9004 als niet aanwezig)

3 - Controle van bit 4 van P2 (moet zijn = 1, status 9024 in tegengesteld geval)

4 - Controle van bit 0 van P4 (moet zijn = 1, status 9024 in tegengesteld geval)

5 - Controle van P3



De gereserveerde handeling van P3 is gelijk aan die van een nanocommando,
maar:

- Moet op zijn minst waarde 10 hebben (status 9024 voor inferieure waardes)

- Is volledig onbekend, samen met data geasocieerd naar P3, voor het
volgende proces:

-> Decrypt SSE ( )
-> DECRYPT SE
-> Parsing en executie

("PARSING", letterlijk vertaald w.d.z. "Analyse van de periode", in onze
context betekend het "examinatie van een nanocommando en zijn parameters")

- Behoord tot de data voor berekening van de 'signature'

Om te weten hoeveel data geasocieerd is aan P3, nemen we de klassieke lijst
van de LEN van de nanocommando:

High Nibble / Nano Lenght
---------------------------
0... C / 0... 12 ( belangrijk : 0 is geen acceptabele waarde voor P3)
D / 16 byte
Y / 24 byte
F / 32 byte

Observatie: P4 is de eerste byte van de data voor P3.



Als laatste voor deze controle kan men status 6700 (error LEN) verkrijgen,
omdat nadat de data van de P3, moeten op zijn minst de 5A bytes (90 in decimalen) verschijnen. De reden hiervoor zal verderop toegelicht worden.

6 - Controle van de bits 1,2 van P4 (moeten zijn = 0, status 9036 in tegengesteld geval)
P4 is indicator voor de-SSE, maar de exacte funktie is nog onbekend.

7 - Decrypt SSE (de-SSE of de-envelope)
Gezien het feit dat de algoritme onbekend is, kunnen we aanschouwen dat
men gebruik maakt van verschillende keys voor elk provider (maar hetzelfde
voor alle kaarten) en deze opereerd altijd en alleen bij de laatste 5A byte van de data. De consequenties zijn:

- Een ECM/EMM geadresseerd naar een provider is niet toepasbaar bij een
verschillende provider.
- de data van P3 (neemt geen deel aan de-SSE) moeten vervolgd worden door
tenminste 5A bytes (dit is de verklaring voor de status 6700 gedurende volgorde van P3)
- Mogelijke bytes bij de data van P3 en de laatste 5A byte nemen geen deel
aan de SSE/envelope (belangrijk).

Voorbeeld:
(Note: De getoonde commando is fictief, correspondeerd aan geen enkele log van data)

C1 40 01 B1S 6A
43 51 6E b1 92 0F 87 17 D3 5C 87 47 34 5E 39 79
12 08 F5 56 DE F0 11 12 D0 D8 40 3B 34 7A EB A5
B7 30 41 50 5F 02 6D B2 03 AB 29 2B 29 7A 05 4F
AF 83 18 75 1F 33 49 67 29 0C C0 22 C7 44 E3 BA
45 6D 1B 3A F3 56 07 A9 89 5D B4 5E 8A D1 1F 40
F4 50 D1 57 D0 96 88 5B EB 93 2A 10 E8 4D 36
1F 80 A7 65 A6 9C 3E 03 78 49

Bij deze commandode bytes in het rood aangegeven hebben betrekking op P3
en de relatieve data (High Nibble van P3 =4, dus 4 data bytes).
De bytes in het geel aangegeven hebben betrekking op 5A bytes onder SSE.
De rest zijn bytes buiten de SSE (zichtbare bytes of SuperEncrypted).


Wat vinden we onder een SSE decrypt?

Een groot verschil kunnen we onmidelijk zie ten opzichte van Seca:
De sigature is extern naar de SuperEcryptie en heeft geen vaste positie.
We gaan terug naar het commando aangegeven bij het voorbeeld met de
veronderstelling van een mogelijke de-SSE:

C1 40 01 B1S 6A
43 51 6E B1S 92 0F 87 17 D3 5C 87 47 34 5E 39 79
D7 C6 1A C9 4F E8 40 6C 67 E3 AB 84 4C 29 3F DD
A3 F0 E6 37 86 6D 8A 23 CB 88 55 9D 47 78 B6 71
54 9F 82 D8 85 1C 3E 05 34 36 27 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 P5 <- ----------------(NU ZICHTBARE P5)

Deze parameter heeft als funktie het aangeven van de positie van nano 82,
dit betekend dat de kaart niet op zoek gaat naar de signature, waarbij
de gehele commando nagaat bij het zoeken naar de nano. Maar het gaat op
"veilige modus" naar de positie aangegeven door P5 . (positie nano 82):

- De signature en lengte van de 8 bytes, het is niet aannemelijk dat
de nano 82 bij de laaste 8 posities van de commando aanwezig is.
- De data voor de berekening van de signature moeten o zijn minst 8 zijn,
en bij andere beeindigigen van nano 82 moeten deze gepaard gaan met op
zijn minst 8 bytes.


8 - Cotrole van de waarde aangenomen door P5

De berekening die de kaart aangaat voor de bepaling va de postitie van
nano 82 is de volgende (berekening a.d.v. 8 bits)

POSITIE 82 = LEN - (P5 +cool

De waardes van P5 tussen 128 en 255 zijn niet geldig (verkrijgt status 9037).
Als P5 = 0 dan verkrijgt men status 9038.
Als P5 de waardes in de rang 1/127 aanneemt verkrijgt men status 9037.

9 - Controle van bit 7 van P2 (moet zijn = 1, status 9035 en tegengesteld geval)

Dit is de bit die de SuperEncryptie aangeeft.

10 - Zoeken naar de key voor de berekening van de signature

Voor de berekening van de signature is de key aangegeven door P2
noodzakelijk; De tweede van de INS geeft aan dat niet alle keys bruikbaar zijn.

INS 40 : Alleen 'richtingaanwijzende' Key (Key Index in rang 0...B) in tegengesteld
geval verkrijgt men status 9013
INS 3C : Alleen Operationele Key (Key Index in rang C...F) in tegengesteld
geval krijgt men status 904A
INS 38 : Enige verbonden data bij bruikbare key.

Hier aangekomen begint het zoeken naar de key in EEPROM, als deze niet
aanwezig is krijgt men status 901D, als men geen primary key vind, of status
901F, als men geen secundary key vind. Eenmaal de key teruggevonden,
gaat men de checksum verifieren, als dit proces faalt dan krijgt men status 9028.



ATTENTIE!!
De status 9028 verktijgt men niet alleen bij het falen van de checksum!!!
Het kan ook tijdens het proces die betrekking heeft op de-SSE verschijnen ,
maar de reden waarom dit gebeurd is op het moment onbekend.
Voor onderscheiding van beide gevallen is het noodzakelijk om een analyse
te doen van de 'respons-tijd'.

9028 pre-SSE : rond de 73000 cyclussen
9028 Key-Checksum : over de 190000 cyclussen



11 - Verificatie van nano 82 en berekening signature

De kaart neemt de waarde van het berekende onder punt 8 en verifieerd of
de nano 82 daadwerkelijk op aangegeven positie bevind.
Als men deze niet vind krijgt men status 9002.
Als nano 82 aanwezig is, dan gaat het met de berekening van de signature verder.
De bytes die afhankelijk zijn van de waarde van de signature verstaan we
allen en alleen de data die betrekking hebben op nano 82 totdat de
inbegrepen P3 gelokaliseerd is.

C1 40 01 B1S 6A
43 51 6E B1 92 0F 87 17 D3S 5C 87 47 34 5E 39 79
D7 C6 1A C9 4F E8 40 6C 67 E3 AB 84 4C 29 3F DD
A3 F0 E6 37 86 6D 8A 23 CB 88 55 9D 47 78 B6 71
54 9F 82 D8 85 1C 3E 05 34 36 27
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 P5

Bij dit voorbeeld alle bytes aangegeven in het blauw nemen deel aan de
berekening van de signature.
De key voor berekening van de signature, wordt door de Nibble onder P2
aangeduid, ondertussen de bits 5,6 de tabellen voor gebruik aangeven.


Bit 6 / Bit 5 /
------------------------------------------
0 / 0 / Tabel ROM (zelfde als Seca)
0 / 1 / Tabel EEPROM (A)
1 / 0 / 'Alternatieve' Algoritme
1 / 1 / Tabel EEPROM (B)
[/LIST]

Als (Bit 6, Bit 5) = (1,0) dan is benodigd om de de decrypt middels
een 'alternatieve' algoritme te executeren, memoriserend in de EEPROM van
de kaart. Bij de v7 is zo'n algoritme niet aanwezig: een mogelijke INS
verstuurd met (Bit6, Bit5) = (1,0) zou men status 9034 moeten krijgen.

De analyse van Bit 6,5 wordt onmiddelijk gedaan voordat men begint met
bevestiging van de aanwezigheid van nano 82.

Het momet is aangekomen voor de berekening van de signature: het is interessant
om de lengte van de commando in de gaten te houden, dat deze geen invloed
heeft op betrokken tijd m.b.t. de berekening.
Dit zou aan kunnen geven dat het gerealiseerd wordt middels de hardware (de crypto-processor).
Als de berekende signature verschillend is van de aanwezige bij de commando
dan is de status die men verkrijgt 9002 (ook wel 9002_B of 9002 type 2 genoemd).

9002_A en 9002_B verschillen tijdens respons-tijd: time(9002_B)> de time(9002_A)

12 - Decrypt SuperEncryption (Decrypt SE)

De decrypt SE gebeurd a.d.h. van 'achtsten', acturerend de bytes die tussen
de P3 en de nano 82 zitten.

C1 40 01 B1S 6A
43 51 6E B1 92 0F 87 17 D3 5C 87 47 34 5E 39 79
D7 C6 1A C9 4F E8 40 6C 67 E3 AB 84 4C 29 3F DD
A3 F0 E6 37 86 6D 8A 23 CBS 88 55 9D 47 78 B6 71
54 9F 82 D8 85 1C 3E 05 34 36 27 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 P5

1- Decrypt SE actueerd verschillend voor de INS 3C, zoals bij Seca ook
het geval was.
2- Anders dan bij Seca, waarbij de incomplete 'achtsten' zichtbaar verschijnen,
hier gebruikt men een proces van psuedo-cryptie van de 8 bytes met
betrekkng op nano 82, om als doel geen enkele data zichtbaar te maken.

13 - Pre-parsing van de 'body' van de INS en executie van de commando

Na de SuperEncryptie moeten we een INS type zoals bij seca, met een
'kanonieke' nanocommando, maar nu heeft het niet dezelfde executie.
Een voorbeeld:

C1 40 01 B1S 5C
10 01 [F0] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF [22] 1A 3F [21] 1A 7F [90] 5D B9 5D 66 CA DE DF FF 00 45
[90] 5C 55 A8 EE 6F 9F 67 AA 92 [90] 5E EF AB 5A 97 FA BC 6F 91 [82] C9 2D C3S 6C
C4 77 74 8B...... ETC. ETC.

De analyse van de nanocommand gebeurd van links naar rechts....

1 + 1 byte 10 01 - P3 en P4, niet beschouwd bij executie van de commando, het verspringd.
1 + 32 byte nano F0 plus 32 data bytes (Customer Word Pointer bitmap)
1 + 2 byte nano 22 - Controle data abonnement
1 + 2 byte nano 21 - Formulering data abonnement.
1 + 1 + 8 byte nano 90 - Beschrijving van primary key (Index 5D )
1 + 1 + 8 byte nano 90 - Beschrijving van primary key (Index 5C )
1 + 1 + 8 byte nano 90 - Schrijven van primary key (Index 5E )

Hier aangekomen bereikt men de nano 82, en verloopt en eindigt correct.
Ervan uit gaande van dit commando:

C1 40 01 B1S 5C
10 01 [F0] FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF [22] 1A 3F [21] 1A 7F [90]
5D 89 5D 66 CA DE DF FF 00 45 [90] 5C 55 A8 EE 6F 9F 67 AA 92 [41]
5E EF AB 5A [90] 5E BC 6F 91 [82] C9 2D C3 6C C4 77 74 8B... etc. etc.


1 + 1 byte 10 01 - P3 en P4, niet beschouwd bij executie van de commando, (overslaan)
1 + 32 byte nano F0 plus 32 data bytes (Customer Word Pointer bitmap)
1 + 2 byte nano 22 - Controle over data abonnement
1 + 2 byte nano 21 - Formulering data abonnement
1 + 1 + 8 byte nano 90 - Beschrijving van primary key (Index 5D )
1 + 1 + 8 byte nano 90 - Beschrijving van priamry key (Index 5C )
1 + 4 byte nano 41 - Beschrijving van PPUA

Hier komt men bij nano 90, dit benodigd 9 data bytes, voorbijgaand aan nano 82.
Dit is een voorbeeld van een 'foute' (slechte) parsing. In ieder geval zou men
status 9600 krijgen (= pre-parsing).




Volgende deel: status 9600 bij versch. INS.

Saludos!

'Azazel miembro del equipo RAIDEN, la resistencia.'

--------------------
LLORAMOS JUNTOS, GANAREMOS JUNTOS!


Bericht opties

Azazel
Sat4all erelid


Lid sinds: 18/05/2002
Berichten: 317
Uit: en las montañas Re: Seca2 FAQ [Re: Azazel]
#291462 - 08/04/2003 20:38 Bewerken Antwoord Citaat Snel antwoord



Status 9600 en de INS 40.

De pre-parsing voor de INS 40 werkt volgens modus zoals eerder beschreven,
de kaart examineert alle nano's voordat men nano 82 bereikt.
Let er wel op dat een gevonden Nanocommand niet perse nodig is dat deze
een betekennis heeft, simpelweg de kaart zal deze overslaan en examineert
de volgende nano, die funktioneert volgens de theoretische lengte van de
onbekende nano.


Status 9600 en de INS 3C - DE BUG.


Met de INS 3C en een 'foute' parsing genereerd men niet altijd status 9600.

Er zijn diverse gedrags verschillen opgemerkt bij het varieren van enige
'body' van de Ins. Vergelijkingen van status 9A00, en ook de pre-parsing
(die verkrijgt men wanneer data van de C1 3C nano 24, 81, 90, 91, F6, F7
bevatten), maar het interessante heeft men wanneer de parsing de vastlegging
van de signature 'uitlokt': In plaats van 9600, krijgt men een bug hetzelfde
als die present is bij de vorige versies van de kaaten: DE BUG.


Zie: BUG in Seca .


Bij de nieuwe kaarten werkt de BUG verschillend, we zien dat bij het eerste
register de primaire MK00 gekopieerd komt van de provider die de C1 3C
aangeeft - De 2e Bug -
Het zou interessant kunnen zijn de bug te proberen bij een provider zonder
MK00, om te kijken wat er dan gebeurd.

Status 9600 en de INS 38 - De bug 36/38

Hier treffen we een 'macroscopische' bug aan die onmiddelijk is verbeterd
bij de v7 kaarten. De routine van controle bij de oude C1 38 verdwijnt en
in de plaats daarvan hetzelfde routine van de pre-parsing die gebruikt wordt
bij de INS 40.

Hierbij is het belangrijk om te weten hoe de pre-parsing van de C1 38
werkte bij Seca 1.
Neem hierbij voorbeeld van secafaq:

Instructies 36 en 38 - Lezen van Record en Signature.

Deze paar van ins. realiseerd het lezen van de aanwezige Records....
Bovendien staat het toe om enige byte van de eventuele aanwezige Record Bx
te veranderen. Eerst moeten de 38 gerealiseerd zijn (versturen van data)
vervolgens de 36 (aplicatie van data).

C1 38 P1 P2 1A 16 xx 2A mm mm 2B nn nn 86 K0 K1 K2 K3 K4 K5 K6 K7 82 Signature

De waardes 16, 2A, 2B, 86 zijn geen echte nanocommands, het is nodig dat
deze op goede posities staan. De status error is hier 96 00 .

P1 en P2 hebben dezelfde betekennis al van de INS 40, PK of PK+SK, deze
kunnen gebruikt worden en zijn bruikbaar voor de SUPERENCRYPTIE.

De waardes 'xx' geven de type register van de DUMP aan, ondertussen geven
de bytes 'mm mm' een offset aan.

00 vv vv Provider Package Bitmap Record

01 vv vv Provider PPV Credit record vv vv = enige waarde

03 xx xx Provider PPV record xx xx = bevat EventID van de PPV

04 00 yy Record Ex yy = specificeerd de Record Ex om te zoeken

06 zz zz Record zz zz = Record nr. om de 'lectuur' te beginnen


In het geval dat 'xx' gelijk is aan 03 , bovendien tonen van de PPV Record,
zal de ins de PPV-Event Spot veranderen, die de 10e en 11e byte is (beginnend
vanaf links) van de gebruikte Record die twee waardes bijvoegd gevolgd aan 2B.
Daarna de waarde 86 gevolgd door 8 bytes.


De werkelijke DUMP wordt gerealiseerd met de Ins 36

C1 36 P1 P2 LEN

P1 moet hetzelfde als P1 van de vorige ins zijn met de zesde bit in
plaats van een.
P2 geeft, zoals altijd, de key aan.
Len moet meer zijn als 13 (in hexadecimaal).


Nu is het niet meer noodzakelijk de aanwezigheid van waardes 16, 2A, 2C, 86,
vanaf de BUG 36/38.

C1 40 01 B1 5C
10 01 7E 3C 29 03 1B AC 43 31 82 A1 7E AE C4 26
96 F2 3E 0A C3 9E 76 3E C6 20 86 79 2E 4A 8D D9
18 14 95 3B 2E B6 54 D2 89 5F 76 0B 23 3B 63 4D
BF 00 EA 81 E5 24 BB 93 CA D4 D0 6F F8 38 5F 9C
5B EF AB 11 33 9B 17 8A EC CC 1D 6B 90 5D CD 2F
50 2C 90 A7 BE 29 68 37 7C 56 6F 33 [90 00]



Bij de voobeeld van de C1 40 is de status byte 90 00 , in werkelijkheid
bestaan er zoals C1 40 met verschillende statussen en hetzelfde bruikbaar
voor de Bug. De meest frequente statussen zijn:

- 97 xy
- 90 19
- 93 01
- 90 09




De 40 veranderen in 38....

C1 38 01 B1 5C
10 01 7E 3C 29 03 1B AC 43 31 82 A1 7E AE C4 26
96 F2 3E 0A C3 9E 76 3E C6 20 86 79 2E 4A 8D D9
18 14 95 3B 2E B6 54 D2 89 5F 76 0B 23 3B 63 4D
BF 00 EA 81 E5 24 BB 93 CA D4 D0 6F F8 38 5F 9C
5B EF AB 11 33 9B 17 8A EC CC 1D 6B 90 5D CD 2F
50 2C 90 A7 BE 29 68 37 7C 56 6F 33 [90 00]

Attentie: Als men probeert hetzelfde te doen met een INS 36 verkrijgt men\
niet hetzelfde resultaat:

C1 36 01 BD 5C
10 01 E6 12 CC 77 60 AE 96 FF F4 4D 58 03 99 F1
3F EF F3 A4 44 E6 1B 16 18 21 EB 40 D4 65 BC F5
66 60 6D 7D 54 29 28 06 52 95 29 D6 07 E0 11 23
1C 8E 89 29 89 2A 43 4E 11 98 2A 63 35 DB 56 F4
4B 03 82 B2 66 29 69 80 69 50 68 FC EC 0 2E 3B
F2 A7 BC 04 CA A8 15 D9 60 7D 28 47 [90 00]

C1 38 01 BD 5C
10 01 E6 12 CC 77 60 AE 96 FF F4 4D 58 03 99 F1
3F EF F3 A4 44 E6 1B 16 18 21 EB 40 D4 65 BC F5
66 60 6D 7D 54 29 28 06 52 95 29 D6 07 E0 11 23
1C 8E 89 29 89 2A 43 4E 11 98 2A 63 35 DB 56 F4
4B 03 82 B2 66 29 69 80 69 50 68 FC EC 0B 2E 3B
F2 A7 BC 04 CA A8 15 D9 60 7D 28 47 [90 02] <------ of [90 34]

Conclussie:
Vanaf de byte van encryptie, geeft de de-SSE van de INS 3C een verschillend
reslultaat dan die van de INS 40/38.
De gebruikte key of het begin van de algoritme zouden verschillend kunnen
zijn, of verschillend betreffende de P5 die zich zonder twijfel in de
goede positie bevind.

We gaan terug naar de C1 38 met status 90 00 ..... dit resultaat staat ons toe om een succesvolle C1 36 te versturen.

C1 36 P1 P2 LEN

Laten we de verbindingen en graden gerelateerd aan deze ins. nader
onderzoeken en analyseren.

P1 moet hetzelfde zijn als 2y of 3y waarbij de 'y' hetzelfde hoort te
zijn als de Nibble van de P1 van de C1 38 voorafgaand verstuurd.

P2 geeft de key en de Hahs tabellen aan die gebruikt worden voor de
encryptie van de responsen (hetzelfde betekennis als C1 38/3C/40).

LEN moet groter zijn dan 13 (in hexadecimaal), van de andere kant
moet de staus 6700 zijn.

De respons die men verkrijgt is hangt af van de 'body' van de INS 38
die men verstuurd heeft, zoals bij volgende voorbeeld:

C1 38 P1 P2 LEN

P3 + data van P3 + 16 d1 2A d2 d3 2B d4 d5
86 K0 K1 K2 K3 K4 K5 K6 K7 82 s0 s1 s2 s3 s4 s5
s6 s7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 P5

De kaart controleerd hierbij niet op de aanwezigheid van de "nano",
maar verwijderd de data direct "d1", "d3 2", d5 4", "K0... K7".

Beginnend te tellen bij de byte vanaf degene die onmiddelijk de data
van de P3 opvolgt, zullen de data worden verwijderd volgens volgende criterium:

- De tweede voor d1
- De vierde en vijfde voor d3 d2
- De zevende en achtste voor d5 d4
- Van de tiende t/m de zeventiende voor K0... K7.

Voorbeeld:

C1 40 01 B0 61
10 01 92 BD 1F C2 E6 A6 C0 8B 1E F7 02 1E 7D F0
07 F2 31 2B 31 46 9E E9 1F 28 65 0D 12 68 F6 F1
25 B2 91 66 63 C0 EA 48 7D E3 1F EB E0 99 92 37
26 86 DB 0E C6 92 13 CD 61 E7 4C 70 45 27 2F A6
D9 B2 74 0C DF 7C E4 07 5D 62 B1 DD B0 13 F5 8C
9E 2A F2 28 12 55 1E 8D 76 43 19 31 01 6E B1 92
11

Veranderen naar C1 38...

c1 38 01 b0 61
10 01 92 BD 1F C2 E6 A6 C0 8B 1E F7 02 1E 7D F0
07 F2 31 2B 31 46 9E E9 1F 28 65 0D 12 68 F6 F1
25 B2 91 66 63 C0 EA 48 7D E3 1F EB E0 99 92 37
26 86 DB 0E C6 92 13 CD 61 E7 4C 70 45 27 2F A6
D9 B2 74 0C DF 7C E4 07 5D 62 B1 DD B0 13 F5 8C
9E 2A F2 28 12 55 1E 8D 76 43 19 31 01 6E B1 92
11 [90 00]


De data worden pas verwijderd nadat deze duidelijk (decrypt) zijn.
Ervan uitgaande dat de decrypt het volgende is:

10 01 10 02 17 00 10 03 80 00 80 00 00 00 00 00
22 00 80 90 51 DE E2 04 D1 AF B3 FB B6 91 51 A1 37 9E
4B D0 49 4C 51 21 1A 7F 90 5C 75 13 DE 05 65 03
C4 57 B0 66 75 63 6B 20 26 20 73 75 63 6B 90 5D
9D 33 0E A2 6C 2D 3C 05 90 5E 06 73 8A B7 5D 9A
4C 5C 41 09 C3 22 21 82 D3 E8 54 CA 78 CD D2 61
P5

.... Men begrijpt nu wat de verwijderde data is (aangegeven in rood) en gebruikt voor de volgende C1 36.


Привет отГоланцев,молодцы ребята

Никогда не думал что у них язык с немцами схожий.Продолжение следует



Een van de vele projecten waarmee men nu bezig is, is natuurlijk de zoektocht naar het algoritme, die nu gebruikt wordt voor seca2.
Er zijn in het verleden diverse serieuze pogingen gedaan om succes te boeken m.b.t. de algoritme, maar allemaal tevergeefs.
Opnieuw wordt er een serieuze poging gedaan naar de zoektocht van de algoritme, en het lijkt erop dat er positieve vorderingen gemaakt zijn.
(Later meer hierover).

Om de zoektocht te beginnen is het natuurlijk van belang om te weten wat de algoritme eigenlijk is en wat hij doet...
De meesten van ons zullen dit waarschijnlijk al weten, maar toch wil ik hier een beknopte uitleg geven:
Natuurlijk is deze informatie op vele site's te lezen, maar het is toch handig als we met de basis beginnen en het hier op het forum geplaatst wordt.
(dat scheelt weer wat zoekwerk...)

-------------------------------------------------------------------------------

Symmetrische en asymmetrische systemen

- Bij symmetrische systemen wordt slechts een sleutel gebruikt.
- Bij asymmetrische systemen een sleutelpaar.


Asymmetrische systeem

Bij asymmetrische systemen wordt door beide partijen een sleutel afgesproken waarmee het bericht zowel versleuteld als ontsleuteld kan worden. Een van de nadelen van dit systeem is dat je dan eerst een veilig kanaal moet vinden om die sleutel af te spreken, en dat zou moeilijkheden kunnen opleveren.
Op zich heeft dit systeem twee funkties:
- Het versleutelen van de data
- Verificatie van de indentiteit van de 'zender'.
Dit systeem is op basis van de 'trapdoor funkties'. Elke deelnemer heeft dan twee sleutels: de openbare sleutel en de geheime sleutel (of privé sleutel).
De geheime sleutel mag dus niet bekend worden, maar de openbare sleutel kan verspreid worden naar iedereen die de eigenaar van de openbare sleutel een bericht wil sturen. Iemand die met een openbare sleutel een bericht codeert, kan niet met dezelfde openbare sleutel het bericht decoderen, dus het is geen ramp als de openbare sleutel bij iemand terechtkomt die er minder goede bedoelingen mee zou hebben.
Een ander nadeel van de asymmetrische cryptografie is dat het decoderen wel 100 tot 1000 keer langer duurt dan symmetrische cryptografie.

Daarom wordt asymmetrische cryptografie vaak alleen gebruikt om een symmetrische sleutel door te geven.

Voorbeeld: A en B willen veilig kunnen communiceren, maar asymmetrische cryptografie duurt hen te lang. Daarom willen ze symmetrische cryptografie nemen, maar het risico is te groot dat bij het uitwisselen van de geheime symmetrische sleutel iemand die sleutel te zien krijgt, en zo dus alle berichten die verstuurd worden kan decoderen. Daarom nemen A en B eerst allebei een asymmetrische geheime en openbare sleutel. De openbare sleutels maken ze aan elkaar bekend, en wisselen met het asymmetrische systeem de symmetrische geheime sleutel uit. In het vervolg gebruiken ze alleen nog maar het symmetrische systeem om hun berichten te (de)coderen. Een bericht dat asymmetrisch wordt gecodeerd, wordt precies hetzelfde gecodeerd als een symmetrisch bericht, alleen zijn de sleutels verschillend. Dus: eerst het bericht omzetten in een reeks cijfers, daarna in blokjes opdelen, daarna coderen met de openbare sleutel van de ontvanger en versturen. De ontvanger decodeert hem met zijn geheime sleutel, voegt de blokjes bij elkaar en zet de cijferreeks om in letters.

Twee belangrijke assymetrische systemen zijn o.a. de RSA en ECC.

RSA

Met dit systeem kan men een geheime sleutel over een 'onveilig' kanaal sturen zonder dat er van te voren via een veilig kanaal andere geheimen afgesproken moeten worden. Met die afgesproken sleutel kun je vervolgens data versleutelen.
De uitwisseling van vertrouwelijke gegevens is wel kwetsbaar. Daarom werd in 1992 het Station-to-Station (STS) protocol ontwikkeld dat digitale handtekeningen en public-keycertificaten toevoegt aan het D/H algoritme.
RSA is een public-key cryptosysteem dat zowel versleuteling als digitale handtekeningen en is gebaseerd op het wiskundige gegeven dat het makkelijk is om twee grote priemgetallen met elkaar te vermenigvuldigen, maar dat het uitermate moeilijk is om uit het product de twee priemgetallen weer te onttrekken, dus:


n=a*b

Vervolgens wordt een getal 'e' bepaald zodanig dat:

3 < e < (a-1)(b-1)

en de grootste deler van 'e' en (a-1)(b-1) is 1, ofwel 'e' is relatief priem tov (a-1)(b-1).
Mbv dit getal e wordt getal d berekend zodanig dat:

d*e=1 mod (a-1)(b-1)

'd' is dus de inverse van 'e'. De openbare sleutel bestaat nu uit het getallenpaar (e,n). De grootheden a, b en d zijn geheim. Het maken van de versleutelde code gaat als volgt. De originele boodschap wordt opgedeeld in blokken B en:

Code=B^e mod n

De werking van het systeem berust op het feit dat 'e' weliswaar gemakkelijk uit 'd' berekend kan worden, maar niet andersom. Het is bijna ondoenlijk om 'd' op basis van alleen de openbare sleutel (e,n) te berekenen. Voor de berekening van 'd' moeten ook 'a' en 'b' bekend zijn.


(Bron -> http://www.argo.es/~jcea/artic/hispasec93.htm)

ECC

Bij ECC ofterwijl Elliptic Curve Cryptosystem, worden de sleutelparen gegenereerd door de priemgetallen-truc. Dit heeft weinig extra voordelen ten opzichte van RSA. Maar ECC heeft een ander mogelijkheid, nl. dat het gebruik maakt van discrete logaritmen in combinatie met een elliptische curve. Voordeel hiervan is dat de sleutellengte korter kan zijn dan bij normale asymmetrische systemen, terwijl de sleutel toch even sterk is.
Om een goede keuze te kunnen maken voor de sleutellengte in functie van het gewenste veiligheidsniveau, zijn gegevens nodig over de kost om een bepaalde sleutellengte te kraken. Die kost kan geschat worden, maar enkel op een nauwkeurige manier als het ontwerp van het kraaksysteem vrij ver wordt doorgevoerd. Daarbij is het geweten dat voor ECC's het gebruik van speciaal ontworpen hardwarecomponenten aangewezen is, dit in tegenstelling tot RSA.

Volgende deel Symetrische systemen.

Saludos!

--------------------
LLORAMOS JUNTOS, GANAREMOS JUNTOS!


Bericht opties

Azazel
Sat4all erelid


Lid sinds: 18/05/2002
Berichten: 317
Uit: en las montañas Re: De zoektocht naar het algoritme [Re: Azazel]
#400252 - 12/09/2003 01:22 Bewerken Antwoord Citaat Snel antwoord



Hallo satvrienden,

We gaan verder met de symetrische systemen.

Symmetrische encryptie is encryptie waarbij 1 sleutel zowel gebruikt word bij het encrypteren als het decypteren. Dus de ontvanger en de zender hebben beiden dezelfde sleutel nodig. Persoon A stuurt dus iets met sleutel Z naar persoon B. Als persoon B sleutel Z heeft, dan kan hij aan de gegevens, anders niet. Als iemand het bericht kan onderscheppen, kan hij er niets mee doen, omdat hij sleutel Z niet heeft.

Er zijn vele verschillende symetrische systemen, o.a. Blokversleuteling, DES, 3DES, IDEA, CAST, Blowfish, Stream Cipher, RC4.
Veelgebruikte zijn o.a. DES en Blowfish.
RC4 is het systeem waarvan men vermoed dat seca2 gebruik maakt. Ik zal later dit systeem uitgebreid behandelen en de diverse tests en proeven die er inmiddels zijn gedaan om dit te kunnen bevestigen.

We beginnen eerst met de DES.

DES

DES is een vrij oude systeem en het is op basis van blokversleuteling, en is in de eerste instantie ontworpen voor de versleuteling en ontsleuteling van blokken van 64 bits.
De sleutel is ook 64 bits lang, maar er worden maar 56 bits werkelijk gebruikt. Voor de te onderscheiden bewerkingen worden meestal verschillende sleutels gebruikt die afgeleid zijn uit de hoofdsleutel. De source-code die ten aan de basis liggen aan de verschillende stappen bij DES, zijn geheim. De werking is alleen vrijgegeven in de vorm van weinig overzichtelijke tabellen.
Vanwege de korte sleutellengte van 56 bits zou DES makkelijk te kraken zijn, en inderdaad is dat gebeurd.

3DES

3DES, ook wel TripleDES genoemd, maakt gebruik van het originele DES algoritme. Maar in plaats van een 56 bits sleutel, worden twee of drie sleutels van elk 56 bits gebruikt. Bij DES-EEE3 worden de data drie keer versleuteld met drie verschillende sleutels (Encrypt-Encrypt-Encrypt). DES-EDE3 gebruikt ook drie verschillende sleutels, maar nu worden de data versleuteld met de eerste sleutel, ontsleuteld met de tweede (waar dan natuurlijk een enorme brei uit komt) en weer versleuteld met de derde (Encrypt-Decrypt-Encrypt). DES-EEE2 en DES-EDE2 doen hetzelfde als de hiervoorstaande, maar dan zijn de sleutels voor de eerste en derde operatie hetzelfde en worden dus twee sleutels gebruikt. In 3DES gaan we ervan uit dat er geen andere mogelijkheid is om DES te breken dan via brute force en dan is de sterkte dus afhankelijk van de sleutellengte. De formule EDE2 heeft als effect dat de uiteindelijke data versleuteld zijn met een sleutel van ongeveer 112 effectieve bits.
Als de key van 128 bits gevormd is door twee dezelfde keys van 64 bits (C1=C2), dan zal het systeem zich gedragen als een 'eenvoudige' DES.
Na een uitgebreide proces naar de zoektocht van de compabiliteit met DES, die overigens 3 jaar heeft geduurd, gebruikt 3DES 3 verschillende keys, waarmee dit systeem veel robuuster is, (men kan keys bemachtigen met lengtes van 192 bits (effectief 168 bits).

Bron -> http://www.htmlweb.net/seguridad/cripto/cripto_7.html

Blowfish

Dit systeem is op basis van een simpel systeem maar vrij bruikbaar; Het verdeeld een byte in drie blokken van bits op een zodanig wijze dat deze blokken zich weer verdelen in drie andere bytes.
De laatste drie bytes zijn de bytes van een blok die de data bevat waarbij men deze data kan modificeren of terugzetten zonder dat de informatie die deze data bevat 'beschadigd of aangetast' wordt.

Hieronder een voorbeeld:

We hebben een beeld van 100x100 pixels en 24 bits kleur. Dit betekend dat de map samengesteld is uit 10000 pixels die dus 30000 bytes bevat.
Elk van deze bytes correspondeerd met de drie hoofdkleuren; rood, groen en blauw.
1 pixel -> 3 bytes
1 byte van rood (0-255)
1 byte van groen (0-255)
1 byte van blauw (0-255)
totaal =24 bits informatie per pixel
De aplicatie zou als volgt moeten zijn: nemende een byte van de informatie die
we willen 'verbergen', verdelen we in 3 blokken, twee van 3 bits en een van 2 bits (totaal 8 bits). Vervolgens worden deze groepen samengevoegd bij elk van de bytes die de pixel maakt.
Als eindresultaat van deze 'operatie' zouden we een foto verkrijgen van 24 bits
maar dan een 67% van het origineel. We kunnen met ons blote oog het verschil tussen de origineel niet waarnemen.
Verder zijn natuurlijk meerdere toepassingen mogelijk via dit systeem.

Volgende gedeelte de RC4 systeem.

Saludos!



--------------------
LLORAMOS JUNTOS, GANAREMOS JUNTOS!


Bericht opties

Anoniem
niet geregistreerd




Re: De zoektocht naar het algoritme [Re: Azazel]
#400814 - 12/09/2003 20:49 Bewerken Antwoord Citaat Snel antwoord



Beste Azazel,

Vergeet de alom gebruikte PGP versleuteling niet (waarschijnlijk RSA versleuteling). Zie site: http://www.win.tue.nl/wire/Activiteiten/...ilig_is_PGP.htm

Bewerkt door deman (12/09/2003 20:54)

Bericht opties

Azazel
Sat4all erelid


Lid sinds: 18/05/2002
Berichten: 317
Uit: en las montañas Re: De zoektocht naar het algoritme [Re: deman]
#400974 - 13/09/2003 00:03 Bewerken Antwoord Citaat Snel antwoord



Hallo satvrienden,

PGP (Pretty Good Privacy) is natuurlijk ook een van de systemen die wordt gebruikt voor versleuteling van diverse toepassingen.
De maker van PGP (Phil Zimmerman) heeft op basis van het RSA algoritme een beter en veiliger systeem willen ontwikkelen. Hieruit kunnen we concluderen dat PGP geen RSA is.
Wel maakt PGP gebruik van RSA; PGP kiest een willekeurig 128 bits sleutel, codeert het bericht daarmee en codeert vervolgens die sleutel met RSA.
Ook maakt PGP gebruik van IDEA (International Data Encryption Algorithm) algoritme. IDEA is een iets uitgebreidere versie van DES.
PGP genereert bij encryptie een unieke IDEA sleutel waarmee het bericht versleuteld wordt. Deze IDEA sleutel wordt daarna weer met RSA versleuteld.

Dit is een uiteraard een zeer korte uitleg betreffende de PGP versleuteling, voor meer info kun je bovenstaande link, aangegeven door Deman uitgebreidere informatie lezen.

Met dank aan Deman.

Saludos!

--------------------
LLORAMOS JUNTOS, GANAREMOS JUNTOS!


Bericht opties

Azazel
Sat4all erelid


Lid sinds: 18/05/2002
Berichten: 317
Uit: en las montañas Re: De zoektocht naar het algoritme [Re: Azazel]
#400988 - 13/09/2003 00:42 Bewerken Antwoord Citaat Snel antwoord



Hallo satvrienden,

We hebben nu een aantal algoritmes behandeld, naar mijn mening de belangrijkste en vooral de basis van alle andere versleutelings systemen die er zijn of nog ontwikkeld zullen worden.

Nu is natuurlijk de vraag:

Welk systeem wordt gebruikt door Seca2?

Om dit te kunnen onderzoeken moeten we rekening houden met vele factoren en dan nog is het moeilijk om hier achter te komen gezien het feit dat vele algoritmen varianten zijn van..... en dus veel op elkaar lijken.
In een topic van mij op 19-09-2002 had ik al het een en ander daarover geschreven:


Citaat:
--------------------------------------------------------------------------------

Het algo van seca2 lijkt verdacht veel op die van seca1, vanuit gegaan wordt dat het hetzelfde is (lijkend op DES), maar de tabellen zijn verschillend.



--------------------------------------------------------------------------------



Vooral vanuit Italie wordt er gezegd dat seca2 gebruik maakt van een algoritme type RSA. Dit is iets waar we natuurlijk al die tijd rekenng mee hebben gehouden en een beetje al vanuit zijn gegaan...
De vraag is natuurlijk hoe onderzoeken we dat???

Dat doen we door middel van Criptanalysis .

Criptanalysis wordt gebruikt voor het ontdekken van encryptie methodes en decoderen van gecodeerde berichten. Het wordt ook gebruikt voor vergelijking van versleutelde data (data-veiligheid).
Enkele encryptie methodes zijn wat meer vatbaarder of gevoeliger voor 'cryptanalysys' aanvallen dan anderen. Daarom wordt er bij het ontwikkelen van nieuwe systemen of verfijning van bestaande systemen hiervoor al rekening gehouden.

Het bestuderen van cryptanalysis is ontzettend moeilijk mede doordat er eigenlijk geen standaard manuals of dergelijke van bestaat en je moet een behoorlijke wiskundige achtergrond hebben om hiermee aan de slag te gaan.


Voor de echt geinterreseerden is er een manual (in het engels) van Bruce Sneier over de zelfstudie van Cryptanalysis.

Deze documenten kun je op de site van duwgati downloaden. Ga naar het Download Archief -> Seca-divers -> Seca2 en download de file CryptAnalysis.zip

Saludos!


--------------------
LLORAMOS JUNTOS, GANAREMOS JUNTOS!


Bericht opties

Anoniem
niet geregistreerd




Re: De zoektocht naar het algoritme [Re: Azazel]
#402107 - 14/09/2003 21:32 Bewerken Antwoord Citaat Snel antwoord



@Azazel,

Op basis van het gegeven dat de software in de satelietontvangers niet is veranderd moet de conclusie zijn dat alleen de datastroom van ontvanger naar de SECA2 kaart (O2S)encrypted is. Encrypted data van de SECA2 kaart naar de ontvanger (S2O) kan niet zonder aanpassing van de software in de ontvanger worden omgezet in plain data. In de data S2O moeten daarom regelmatigheden kunnen worden ontdekt. Dit geldt ook voor de code in data O2S. Bepaalde fragmenten kunnen vanwege de onveranderde software in de ontvanger niet zijn gecodeerd. Dus voordat we kunnen beginnen met cryptanalysis is het van belang om te weten hoe het gecodeerde deel is opgesloten in de data van O2S. Kun je daar iets over uitleggen?


Bericht opties

Azazel
Sat4all erelid


Lid sinds: 18/05/2002
Berichten: 317
Uit: en las montañas Re: De zoektocht naar het algoritme [Re: Azazel]
#406340 - 20/09/2003 14:19 Bewerken Antwoord Citaat Snel antwoord



Hallo satvrienden,

We vervolgen onze zoektocht naar het algoritme, en zoals op enkele Italiaanse forums wordt beweerd maakt seca2 gebruik van RC4 Algoritme.
Dit was voor ons een reden om dat eens uit te gaan zoeken.

Dus dat betekend dat het weer afgelopen is met de schaarse vrije tijd en flink aan de slag!

De eerste vraag die meteen komt opduiken is natuurlijk:

Wat is RC4?

Tsja, wat RC4 is, dat weten we eigenlijk wel, maar hiermee wordt eigenlijk bedoeld: hoe gaat RC4 te werk?




- RC4 is een van de snelste ciphers (codering) wereldwijd gebruikt voor het serieuze werk.
- Variabele key lengte van 40 tot 256 bit key.
- De lengte van de te coderen tekst is even lang als de gecodeerde tekst.
RC4 gebruikt twee arrays van bytes (van 8 bits). The "status" array is 256 bytes en bevat een permutatie van de nummers 0 t/m 255. The "sleutel" array kan elke lengte tot 256 bytes hebben. RC4 gebruikt ook twee indexvariabelen, i en j, die op nul beginnen. Alle variabelen zijn 8 bits en alle optellingen worden gedaan modulo 256.

RC4 heeft twee fases: het initialiseren van de sleutel en de eigenlijke versleuteling. De initialisatie wordt maar 'e'en keer per bericht gedaan en begint met het zetten van de hele status array zodat het eerste element de waarde nul heeft, het tweede de waarde 'e'en, het derde de waarde twee, enzovoort.

De status array wordt dan 256 keer door een mengoperatie gehaald door middel van een lus die i door de waarde nul tot 255 laat stappen. Elke mengoperatie bestaat uit twee stappen:

Tel bij de variabele j the waarde van het i'de element van de status array en het n'de element van de sleutel, waarbij n gelijk is aan i modulo the lengte van de sleutel.
Verwissel het i'de en het j'de element van de status array.
Nadat de lus klaar is, worden i en j weer op nul gezet.

Tijdens de versleutelingsoperatie worden de volgende stappen voor elke byte van het bericht doorlopen:

De variabele i wordt met 1 verhoogd. De waarde van het i'de element van de status array wordt bij j opgeteld. Het i'de en j'de element van de status array worden verwisseld en tevens bij elkaar opgeteld om een nieuwe waarde n te vormen.
Het n'de element van de status array wordt dan via een bit-voor-bit exclusive-or met het byte van het bericht gecombineerd
om de uitvoerbyte te vormen.
Deze stappen gelden zowel voor encryptie als voor decryptie.

In CipherSaber bestaat de RC4 sleutel array uit het password dat de gebruiker invoert gevolgd door een 10 byte lange initialisatievector (IV).

Wanneer je een bestand versleutelt, genereer je een nieuwe IV met random waardes en schrijf je deze tien bytes weg in het uitvoerbestand alvorens de versleutelde bytes van het bericht te schrijven.
Wanneer je een bestand ontsleutelt, lees je de eerste tien bytes van het invoerbestand en gebruikt deze als IV.


Als we vervolgens naar de code kijken kun je zien dat deze niet moeilijk is in te brengen / toe te passen:

Dim Keyx(255) As Integer
Dim S(255) As Integer
Dim K(255) As Integer
Dim NumeroBits As Integer

NummerBits = 256 'Nº bits van 40 tot 256

For i = 0 To Len(Text3.Text) - 1 'Text3.Text is de symetrische key
Keyx(i) = Asc(Mid(Text3.Text, i + 1, 1))
Next
For i = 0 To NummerBits - 1
S(i) = i
K(i) = Keyx(i Mod Len(Text3.Text)) 'Lengte van de symetrische key.
Next
j = 0
For i = 0 To NummerBits - 1

j = (j + S(i) + K(i)) Mod NummerBits '<-- een van de RC4 algoritmes
medium = S(j) '
S(j) = S(i) '
S(i) = medium '

Next
n = 1
i = 0
j = 0
Do
i = (i + 1) Mod NummerBits
j = (j + S(i)) Mod NummerBits
medium = S(j)
S(j) = S(i)
S(i) = medium
t = (S(i) + S(j)) Mod NummerBits
keystreamByte = S(t) 'we erkrijgen de key waarme we de XOR bij de plain tekst kunnen toepassen.
Plaintekst = Asc(Mid(Text1.Text, n, 1)) 'Text1.Text is de plaintekst en gaat over op ascii.
n = n + 1
codering = plaintekst Xor keystreamByte 'Men codeert byte voor byte
Text2.Text = Text2.Text & Chr 'Text2. Text is de gecodeerde plaintekst
Loop Until n > Len(Text1.Text).

Controlbyte zegt: De v7 heeft een cryptoprocessor bijgevoegd die het eventueel mogelijk zou kunnen maken om SHA1 en enkele miliseconden uit te voeren. Bovendien time analysis van het proces van 'firm' laat zien dat de berekening van de digest wordt gerealiseerd in blokken van 64 bytes!! Met de toevoeging van enige extra bytes bij het bericht, waarschijnlijk UA, PPUA of SA, naarmate deze correspondeerd.
RC4 zou perfect in het totale plaatje kunnen passen.


PS. Deman, de interne software van de ontvangers krijgen regelmatig een update, waardoor het onderwerp wat jij aanhaalt helaas niet opgaat hier.
Via die weg zal het ontzettend moeilijk zijn om vooruitgang te boeken.


Saludos!

--------------------
LLORAMOS JUNTOS, GANAREMOS JUNTOS!


Bericht opties

Anoniem
niet geregistreerd




Re: De zoektocht naar het algoritme [Re: Azazel]
#406678 - 20/09/2003 21:59 Bewerken Antwoord Citaat Snel antwoord



@Azazel,

Stel dat het de RC4 methode is, dan nog zijn er veel varianten mogelijk. Het geillustreerde basic programmaatje is daar maar een voorbeeld van. Ook kan er variatie zitten in de key lengte. Een voorbeeld die de draadloze netwerkers gebruiken is het WEP (gebruikt ook RC4). De key lengte kun je bijvoorbeeld instellen op 40 of 128 bits. Daarnaast bestaat er ook een variatie in datalengte (vast of continu doorlopend). Belangrijk is om te weten over welk deel van de input- en outputdata de decryptie/encryptie moet worden uitgevoerd.

Op het internet kun je veel vinden over het kraken van het RC4, maar de enige aanpak die op dit moment bestaat gebruikt de brute force attack (simpel weg alle key codes uitproberen) en als je de juiste key hebt dan moet je dat wel doorhebben (dus je moet ook weten hoe de data er ongecodeerd uitziet). Als de key uit 128 bits bestaat dan hoop ik voor je dat je erg gezond leeft want met de huidige technologie moet je een paar duizend jaar worden.


Bericht opties

Azazel
Sat4all erelid


Lid sinds: 18/05/2002
Berichten: 317
Uit: en las montañas Re: De zoektocht naar het algoritme [Re: deman]
#407143 - 21/09/2003 15:56 Bewerken Antwoord Citaat Snel antwoord



Hallo satvrienden,

@Deman, je hebt in zekere zin wel gelijk, via de methode brute force gaat het inderdaad wel wat lang duren, maar voordat we de brute force methode gaan toe passen zijn er toch nog andere mogelijkheden om RC4 te kraken.
Zo zouden we bv. met een INS enige herkenbare byte (vrije) en zijn corresponderende codering proberen te verkrijgen. Men veronderseld dat via deze weg zelfs tot 7 herkenbare / vrije bytes van enige EMM verkregen kan worden gebruik makend van bug 40/38/36.
En er zijn natuurlijk meerdere methodes die ik alle zal gaan bestuderen en toe passen, en verderop hier in dit topic de resultaten publiceren.

Seka2 maakt gebruik van twee overlappende coderingen:
(C1)SE + (C2)SSE

C1 is de blok cipher in CBC. Hierbij is het gemakkelijk om paren van herkenbare tekst / gecodeerde tekst te verkrijgen met C1 gebruik makend van lange INS.

In Alejandria wordt de RC4 voor seca2 al bij voorbaad afgewezen, iets waar ik nog niet helemaal uit ben.
Ik ga voor nu de studie van Supergulp "FAQ Icon of Coil" eens goed doornemen, er schijnen daar interresante gedeeltes te staan.

Voor degene die het 'brute force' methode willen proberen, staat hier beneden de code die men hiervoor kan gebruiken. Er zijn op het net wel meerdere codes openbaar maar deze funktioneerd vrij goed.




Public Function RC4(ByVal Expression As String, ByVal Password As String) As String
On Error Resume Next
Dim RB(0 To 255) As Integer, X As Long, Y As Long, Z As Long, Key() As Byte, ByteArray() As Byte, Temp As Byte
If Len(Password) = 0 Then
Exit Function
End If
If Len(Expression) = 0 Then
Exit Function
End If
If Len(Password) > 256 Then
Key() = StrConv(Left$(Password, 256), vbFromUnicode)
Else
Key() = StrConv(Password, vbFromUnicode)
End If
For X = 0 To 255
RB(X) = X
Next X
X = 0
Y = 0
Z = 0
For X = 0 To 255
Y = (Y + RB(X) + Key(X Mod Len(Password))) Mod 256
Temp = RB(X)
RB(X) = RB(Y)
RB(Y) = Temp
Next X
X = 0
Y = 0
Z = 0
ByteArray() = StrConv(Expression, vbFromUnicode)
For X = 0 To Len(Expression)
Y = (Y + 1) Mod 256
Z = (Z + RB(Y)) Mod 256
Temp = RB(Y)
RB(Y) = RB(Z)
RB(Z) = Temp
ByteArray(X) = ByteArray(X) Xor (RB((RB(Y) + RB(Z)) Mod 256))
Next X
RC4 = StrConv(ByteArray, vbUnicode)
End Function

Ты думаешь все все поняли? Делай перевод тогда,а так содрать с сайта все могут

А тебе самому что в лом транслотором воспользоваться?
Кому надо уже прочитали и перевели каждый для себя ,а тепе если это не надо то ты и наченаешь вопрсы глупые задавать и меня подкалывать....

Все, что выше написано, предназначено исключительно для исследования и изучения seca2.

Никто тебя не подкалывает,Просто здесь много людей не знающих азов SAT TV,А ты если пишешь,то делай разъяснения

В принципе тебе, mag, не надо это читать. Pavlodar же пишет, что это для исследования и изучения Mediaguard2.
А ты хочешь (как и большинство здесь) просто практический смотреть.

   

 
  䀀