New BISS algo? (TESTCA @ 7°E)

campag5242

Feed Hunter
Messages
2,582
I looked at recent .ts recordings:
1. Scrambling control in the PMT is 0x10, so DVB-CISSA here, not CSA3 :D
2. Tuesday's H264 video had FF padding, easily spotted by the trailing 8-bytes of FF on the packets without an AF. And confirmed by the subsequent AF ending ...FF FF 80
3. Since CISSA's AES CBC encrypts the block left to right, the Crypt16 is the same irrespective of payload length.
4. Furthermore, the fact that the CBC crypt is done left to right (not right to left as per CSA) means only one round of AES required for building chains, not 23 rounds of CSA BC as per the B8hx Crypt8s
5. It's still hopeless... :D
 

kebien

Registered
Messages
1,329
But there is another important issue : the ECM decryption algorithm.
There most probably is a security element in the ird that is used for decryption of the ECM that is required to emulate.
Not sure why people is getting ahead into control words,when is easy to assume this will become just like any other encryption that needs to decrypt ECM to get CW,and you could never apply the principles used in BISS.
Forget about getting CW or crypt8,since you don't look for those for any encryption with an ECM.
The only solution you have is to know way the ECM is decrypted (ECM decryption algo),the keys used to decrypt ECM (EMM decryption),a way to make an AES decryption module (for DVB cards emulators),a way to setup the CA device to use AES CA in chipsets (if present)(nautilus was testing this feature for oscam).

So,in spite of the name,this is one more dynamic ecnryption that has nothing in common with BISS,but with any encryption with an ECM.

Nothing has ended,people will eventually try to play with some of this new irds and see if there is a chance in be open.

Who is assuming there is a single CW session when an ECM is present?
why bother finding a 128bit key for 10 seconds of video,in that case?
 
Last edited:

kebien

Registered
Messages
1,329
I mean, is it possible to be a way to break this new key (Biss 2)?

Not until the ECM can be decrypted,and only by taking apart one of those IRDs could be possible to know if there is hope


Is it only me that thinks all irds should have the same content ? (universal keys,universal algo) and the only difference would be unit id?
But is just speculation based on they will not make provider specific CA id and so on
 

thefatty

Registered
Messages
1,550
ECM is not fixed = No fixed BISS key.

How do you know its not fixed?




Also if its an open system, surely that means reverse engineering it will not require access to hardware?

Also it says rolling keys, but doesn't say how often it will roll; it could be seconds it could be hours.

I dont know why they would call it BISS, its more like PowerVU if anything.

As I understand it BISS2 Modes 1,2 and 3(BISS-E) are similar to BISS1, except using IPTV software scrambling algorithms and a AES yes instead of DES. I think i am correct in thinking that hardly no-one uses BISS-E at the moment anyway. BISS-CA is a new option with the rolling keys.

Not sure why they would use an IPTV scrambling algorithm and not develop one specifically for satellite.
 
Last edited:

campag5242

Feed Hunter
Messages
2,582
Sure the test transmissions thus far (one in Feb, two this month that I've logged) have been Biss2-CA 2610 with a crypto period ~29 seconds before swapping odd/even key. Who knows what the prevalent mode will be if/when widely deployed... it might be one of the static modes with caid 2602.

RBT *can* be used for rolling keys if padding is seen inside a crypto period, and the lookup is fast enough (v2 was designed thus). But it's still hopeless here on account of key size, so impossible storage requirements and timescales.

@thefatty it's irrelevant whether biss or biss-e, nett result is the same fixed key (same goes for biss2-1 or biss2-e). There's no way of knowing which static mode is in use, unless you are the bloke in the OB van tasked with injecting the key.
 

nautilus7

VIP
Messages
607
But there is another important issue : the ECM decryption algorithm.
There most probably is a security element in the ird that is used for decryption of the ECM that is required to emulate.
Not sure why people is getting ahead into control words,when is easy to assume this will become just like any other encryption that needs to decrypt ECM to get CW,and you could never apply the principles used in BISS.
Forget about getting CW or crypt8,since you don't look for those for any encryption with an ECM.
The only solution you have is to know way the ECM is decrypted (ECM decryption algo),the keys used to decrypt ECM (EMM decryption),a way to make an AES decryption module (for DVB cards emulators),a way to setup the CA device to use AES CA in chipsets (if present)(nautilus was testing this feature for oscam).

So,in spite of the name,this is one more dynamic ecnryption that has nothing in common with BISS,but with any encryption with an ECM.

Nothing has ended,people will eventually try to play with some of this new irds and see if there is a chance in be open.

Who is assuming there is a single CW session when an ECM is present?
why bother finding a 128bit key for 10 seconds of video,in that case?

Like campag5242 wrote, there is the static mode with caid 2602 as well.

In dynamic CW mode (mode CA), the ECM is encrypted with AES128 CBC. Each ECM carries the 2 encrypted CWs (for CISSA) and an IV for their decryption.

Of course, the ECM key is needed, which is obtained through the EMM (which is encrypted with RSA OAEP 2048). But maybe ECM keys are leaked for each event, and we won't need the EMM keys. Who knows.

The CISSA hardware decryption is already working in Dreambox and Edision STBs with OSCam. I can't tell about other manufacturers. The API is in the code. Who ever is interested can add support for CISSA in their STBs.
 

kebien

Registered
Messages
1,329
campag5242 is right,of course
For static mode search,the size of table grows exponentially,not linearly,if there will be this option.
And the look up time the same.
And having an ecm that can change the session key any time without warning makes a search moot.
I would think they could change keys midway transmission,just a thought.But maybe not.

I'd say there are better odds of extracting the decryption and keys from ird in order to make a lasting emulation,and this extraction could never happen or take a long time.

Then comes the "colibri's" of this hobby to make a fool of all of us and explain absurd unseen weaknesses.
Anything can happen.
 
Last edited:

Shamra

Registered
Messages
196
Why do they need such difficulties, if the key itself in 128 bits immediately blocks the "attack" for several months or even years.
Moreover, as you yourself indicate, the key can be changed at any time.
 

thefatty

Registered
Messages
1,550
Of course anyone with the knowledge to find a weakness will keep quite until mass rollout, else the weakness will be fixed before release into the wild.
 

kebien

Registered
Messages
1,329
I just merely pointed out that the only research should be on ECM decryption,and not in CW brute force.
That's all
 

campag5242

Feed Hunter
Messages
2,582
c16 for this one. And any table you might build over your entire lifetime is going to contain a miniscule fraction of the 2^128 keyspace.
 

kebien

Registered
Messages
1,329
Maybe you and about 5000 other friends have enough space to hold such table.
If a C8 table almost complete is 2TB,do the math about how big a c16 table will be.

NO,is not double the size !!!

should be 2^64 bigger?
I maybe wrong,and still not counting C8 tables are 56 bits.Makes it even bigger
 

campag5242

Feed Hunter
Messages
2,582
Doing the maths for Biss1 rbt v1 (a 48-bit Biss SW, chain length 2^16 or 65536). You need to cover the 2^48 keyspace around 4 times to get coverage over 90%, so a good table will be of size:

4 x (keyspace / chain length) x (byte count chain's start SW + end SW)

For Biss1
4 x 2^48 / 2^16 * 12 = 3x2^36 or around 200MB, your typical v1 Colibri table size.

And the time taken to build such a count of chains is reasonable.

Doing the same for Biss2, 128-bit SW, choosing to make chains 65536 long again:
4 x 2^128 / 2^16 * 32 = 2^119, or 3223802185639011132549803 times the size of the v1 table above. There's no such amount of storage available, nor time to actually calculate that count of chains.

Of course, rbt is a (lookup) time-memory trade off, so you can increase the chain length to reduce storage requirements, but you cannot overcome the unimaginable time taken to cover that huge keyspace once even.
 

orangebirds

Member
Messages
319
Maybe you and about 5000 other friends have enough space to hold such table.
If a C8 table almost complete is 2TB,do the math about how big a c16 table will be.

NO,is not double the size !!!

should be 2^64 bigger?
I maybe wrong,and still not counting C8 tables are 56 bits.Makes it even bigger

CSA used on BISS = 12 digit
CISSA used on BISS2 = 32 digit
Hex = 16
32-12 = 20

it will be theoretically 16^20 bigger than it will be now for each table, and by time too

Also I'd like to ask, according to the EBU document about BISS2-CA, for BISS2-CA we need to know Injected ID or Buried ID, Entitlement Key ID and a Private key pair to decrypt the CW, but I don't understand how long is the actual Injected/Buried ID key and how it will be used to decrypt the ECM and ECW
 

campag5242

Feed Hunter
Messages
2,582
@orangebirds - it's all detailed in the EBU specs: https://tech.ebu.ch/docs/tech/tech3292s1.pdf

Those IDs you mention are for use in Biss2-CA EMMs, which use RSA-2048, so that gives you the length of those keys.

The ECMs are decrypted using AES with an SK derived from the EMM for entitled decoders.

To gain a full understanding, write the specs up in source code - there are examples in the appendix to verify you've done it correctly. Or browse nautilus7's oscam-emu source as a further guide.
 

nautilus7

VIP
Messages
607
The injected and buried ids are needed for biss mode E, if I recall correctly.

For mode CA, a RSA key pair is generated, the scrambler/sender gets the public key and encrypts the data, and the descrambler/receiver decrypts them with the private key.

The private key comes in PEM format and is stored inside the receiver without the operator having access to it. Appendix C1 shows such a PEM file. The ird can accept multiple PEM keys. (One can create his own RSA private keys in PEM format with openssl, but I don't remember the exact command needed).

The operator of the ird can only see an 64bit id created of that private key, called entitlement key id (ekid). The ekid also comes inside the emm, and this way the receiver knows which private key to use for each emm.



I did some bug fixes in the biss2 code, but some fixes are still needed in oscam's dvbapi code.
 
Last edited:

thefatty

Registered
Messages
1,550
For mode CA, a RSA key pair is generated, the scrambler/sender gets the public key and encrypts the data, and the descrambler/receiver decrypts them with the private key.

The private key comes in PEM format and is stored inside the receiver without the operator having access to it. Appendix C1 shows such a PEM file. The ird can accept multiple PEM keys. (One can create his own RSA private keys in PEM format with openssl, but I don't remember the exact command needed).

The operator of the ird can only see an 64bit id created of that private key, called entitlement key id (ekid). The ekid also comes inside the emm, and this way the receiver knows which private key to use for each emm.



I did some bug fixes in the biss2 code, but some fixes are still needed in oscam's dvbapi code.

So if the private key can be retrieved from an ird, decryption would be possible?
 
Top