CSA Brute Force

Still have the idea that a CSA BF in 10 sec would change a lot

Just wanted to know if there are any new findings or idea to the CSA Brute Force which can reduce the key space lower than 2^48?

As far I know you still need
56 rounds of BC
32 rounds of SC init and
12 rounds of SC run could be stopped if result are wrong (easy in software hard in hardware if fully unrolled / pipeline core on fpga are used)

I'm aware of RBT, but I doubt a c8 for 10 sec will tell you what to search for. This problem point back to normal BF approach.

It's possible to do a complete 2^48 BF search in about 12 hours on 1 FPGA, but to reach 10 sec. you will need about 4500 chips = not possible.

Come with your great ideas

MickeEst said:

I think that it is better to make tool first that bruteforce CSA in recordings, not live-tv. Because one can record any encrypted signal with interesting show or movie and then decrypt it later. It's not so critical anymore, how long it takes to decrypt these recordings.

Click to expand...

Sure it has to work on recordings first, you will also have to use recording (buffer) on live since a full search will lets say now take 12 hours this will make an average on 6 hours if you transfer that to 10 sec in average you will have 20 sec to a full search.

So if you have a buffer on a few minutes you might be lucky to have an average on 10 sec for each search.

For full recording you might be able to get a CW list from someone who did a CW logging of a valid card.

The live approach are the interesting goal so you can zap around

We do look for 00 00 01 as shown here with 2 different payloads

Test with key from 00 00 00 00 00 00 to FF FF FF FF FF FF
You should get a hit on 11 22 33 44 55 66

kebien said:

In practice,you do not have 10 seconds,I believe.

As soon as the new ECM packet comes in,the control words is used instantly.But there are two keys in packet,odd and even in buffer.
If takes you 8 seconds to BF the key,you'd only be able to watch video for 2 seconds,then black screen for the next 8 seconds until you find the next key.
This would push you to delay/buffer the video if the idea is to watch live.
I understand what you are looking after.
Tables so far proved to be the fastest so far.

Click to expand...

I agree you will need at least 10 sec buffer of the payload since you do not decode the ECM, but 10 sec black after a zap could be accepted

So the tables you refer to, will they be RBT based on c8?
I doubt you will find enough stuffing bytes in 10 sec packet to use it but I might be wrong, please explain what kind of tables you have in mind?

kebien said:

yes,RBT I reffer to.
And also true you cannot find good enough C8 in that little time.
Specially since the new C8 will be in sync with new ECM packet,now you have 2 things to find,a C8 and after that the key.

I remember in a paper that said the CSA device is not using all bits of the CW to decrypt the video.(of the actual key,not the checksums)
If that is also true then will reduce the BF time.
Maybe starting by assessing how true this is,may help.
We are talking about long shots,right?

I agree with Coder we are not fast enough yet to do any of that... but in the next 10 years an implementation of CSA v3 might be is use with 128-bit key and will become impossible again

Click to expand...

I agree not an easy way, but still it's worth to look for new ideas.

I doubt that some of the bit are not used from the CW.
I have made a more detailed image of CSA part we do look at



If we do look on the BC you will see how each of the rounds takes 8 bit from the CW.
In the next image you see 4 rounds of BC where KK are the 8 bits coming and use as input for the s-box which are an 8x8 (256) LUT



Not sure how you will have some bit not used?

It might be a bit different on the SC (here are 2 rounds)

zayden said:

How do you know you have the right key before returning it to the decoder since many keys will satisfy the checksums ?

Click to expand...

Basic you you grab 2 or 3 blocks where the start bit are set in
the encrypted payload.

Do BF on the first and look for one with result 00 00 01 then you check the forund CW on block 2 and 3 and if they gives 00 00 01 as well you properly have a valid CW.

If you look on my first image you will see 2 rows of inputs and outputs of SC and BC this it from 2 different blocks which both end up in 00 00 01 when XOR together

One small shortcut I did find on the BC while back are like this:

Due to we do have 2 chksum in the cw and it's like a low 3+1 and a high cw 3+1 (total 6+2) it's very logic to divide them as 2 counters a CW low and a CW high each of 2^24.

If you look at the image below you will see BC ONLY use the green part of the CW for the first 4 rounds.

This does mean you only need to the first 4 rounds each time the blue counter starts over, this will reduce the BC time to a factor 52/56



Different study show that the BC are the one taking absolute moste time/space when doing BF.

I recall someone did an analyse of the Cudabiss and found the time for threads of the BC vs SC are like 100:1.

Also on FPGA the absolute resource killer are the BC and in there it's the S-box killing resource/performance.

On FPGA Permutation does not exist (it's just wires)

BC does take the 64 bit payload in at top and then you will do all the combination of CW to get 64 bit out in the bottom (we only need 24bit)

So here comes an idea (not tested yet)

Since each block of 8 rounds do XOR on the CW first with 06 then later with 05 etc. We could have 7 different S-box tables (where the Xor are included) this will save a litle bit of computation time.

But if we to a lookup table with input of 00 00 00 00 00 00 00 00 and go over the complete CW space 2^48 (huge table on a SSD drive)

Could it then be possible "just" xor the CW with the input payload to have the CW to give the result for the input payload?

kebien said:

I remember in a paper that said the CSA device is not using all bits of the CW to decrypt the video.(of the actual key,not the checksums)
If that is also true then will reduce the BF time.
Maybe starting by assessing how true this is,may help.
We are talking about long shots,right?

Click to expand...

I have been thinking about this for a while and been looking over the algo many times and can't see how it should be posible to eliminate some bits of the CW.

I did look through a lot of CW list to see if I coud see some bit's not used, but they all seam to be used now and then.

So I just found a pdf called "Securing digital video. Techniques for DRM and Content Protection"
which says on page 108

On behalf of DVB, a group of international experts defined the DVB Common
Scrambling Algorithm (DVB-CSA) used to protect content. DVB-CSA uses a
40-bit key Control Word.5 DVB-CSA’s crypto period can vary from 10 to 120 s.

Click to expand...

5 In fact, DVB-CSA used a 56-bit key with only 40 bits of entropy. This was to comply with
limiting regulations. Due to the short lifetime of the key, it is assumed to be long enough. A new
version called CSA V2 uses the full range of 56 bits. A newer version CSA V3, using a 128 bit
key, should be deployed in the coming years [217].

Click to expand...

So if this is true then it might be the case that public transmission have to stick to this rule with 40 bit if using CSA1 even the CSA algo does support 64 bit.

Could someone do a CW log of a public channel and post the cw log?

I could be so simple that they do not use every 8th bit