How is it possible to scramble channels with multiple encryptions?

N

norm_

Regular Member
Messages
18
Likes
0
#1
How is it possible to scramble channels with multiple encryptions without sacrificing bandwidth?

E.g. ORF use Irdeto, Cryptoworks and Nagravision, presumably all within the same broadcast.
 
PaulR

PaulR

Dazed and Confused Admin
Staff member
Messages
15,925
Likes
3,163
My Satellite Setup
-----------See sig-----------
My Location
Wirral, NW UK and Vaucluse, France.
#2
I suppose if you think of it like a door with a lock then there is more than one key that can turn the lock. This means that the signal doesn't take up any more space in the spectrum (or at least, a minisculely small amount extra) than a signal with only one encryption.

PaulR
 
S

speculatrix

Regular Member
Messages
26
Likes
1
My Location
East Anglia, UK
#3
I think the way it works, having seen some of the CI/CAM documents, is that the actual encryption algorithm is the same for the commonly used ones , but the method by which the keys are exchanged between the cards and the cams, and the updated keys are passed to the cams, is specific to each system (via, ird, sec, con... etc). This is how the old ird*o freecam can do so much.
The signal stream from the satellite identifies to the cam what type of card should be used and how to use it. A freecam and the matrix and so on remap the card commands and then when it gets the keys applies the appropriate algorithm or variation of it.

s*y/NDS use a non-standard system and they are able to change it, and thus when anyone gets close they can tweak it. They learned some hard lessons from the old analogue days.

naturally, there's a lot of secrecy, both by the companies who make the encryption systems, and by the [cough] unofficial decryption people, and you have to sign quite a lot of paperwork to get access to the core decryption information, but you can find some data on it from the ETSI, the BSI and other standards sites without having to pay anything.

Paul
 
K

kalamar

Guest
#4
The NagraVision cards use a variant of the ISO-7816 protocol called the
"T=1" or "asynchronous half-duplex block transfer" format. This format
differs from the format used by DSS smartcards in that the DSS protocol (the
"T=0" format) calls for the master device (the receiver or IRD) to send a
5-byte header block to the card. The card (or CAM) must then send back one
of the bytes from the header (specifically, the second byte, which is the INS
byte) to acknowledge receipt of the header. At this point, the IRD will
either send the rest of the message to the CAM as one large packet, send the
rest of the packet one byte at a time, awaiting an acknowledgment after each
byte, or await the data return from the CAM.
The T=1 protocol, on the other hand, is defined such that any of 7 devices
all connected to the same ISO-7816 bus may initiate a transmission to any
of the other devices on the bus. In addition, the message will either be
sent all at once (if it is short enough to fit in the destination device's
receive buffer), or broken into smaller packets if the message is too long
to be sent all at once.
The protocol used by the NagraVision smartcards (and in fact, by any
ISO-7816 compliant smart card) is requested by the card when it is reset by a
master device. After reset, the card will send a sequence of data at a fixed
baud rate (input clock frequency/372...it seems like an arbitrary number, but
if the input clock frequency is 3.579545 MHz, the baud rate is 9622 bps...and
although 3.579545 MHz seems like a strange number, it's actually pretty
common: It's the frequency used by the colorburst crystal in NTSC televisions
and set-top boxes), and this data will include information about the data
format the card wants to use, the baud rate at which it will want to
communicate, and so on. To better understand the NagraVision cards, let's
look at the ATR sent by a ROM3 Nagra card (specifically, this ATR came from an
EchoStar 288-02 card, but the same ATR has been seen from cards used for
ExpressVu, SkyVista, and Via Digital):

3F FF 95 00 FF 91 81 71 64 47 00 44 4E 41 53 50
30 30 33 20 52 65 76 3x 3x 3x nn

If we break this ATR up into its constituent parts, we can decode it as
follows:

3F ... Convention definition
|
|_____________ Inverse convention (data is inverted)

FF 95 00 FF 91 ... Initial parm setup
| | | | |
| | | | |_ Td1=91 (Ta2 and Td2 will be sent, Protocol is async
| | | | half duplex block format)
| | | |____ Tc1=FF (Guard time=257 bits)
| | |_______ Tb1=00 (No Vpp)
| |__________ Ta1=95 (F=512, D=16; Bit period=(512/16) (32) clocks)
|_____________ T0=FF (Ta1, Tb1, Tc1, and Td1 will be sent, 15
historical characters will be sent)

81 71 ... Secondary parameters
| |
| |__________ Td2=71 (Ta3, Tb3, and Tc3 will be sent, protocol is async
| half duplex block format)
|_____________ Ta2=81 (Mode change not allowed, Protocol is async half
duplex block format)

64 47 00 ... T=1 specific parameters
| | |
| | |_______ Tc3=00 (LRC (XOR-type) error checking to be used)
| |__________ Tb3=47 (Char wait time is 25 bit times, block wait time
| is 634.9 mSec + 11 bit times) (1 bit time=7.111
| uSec)
|_____________ Ta3=64 (Receive block size=0x64 bytes (100 bytes decimal)

44 4E 41 53 50 30 30 33 20 52 65 76 3x 3x 3x ... Historical bytes
| |
|_____ ___________________________________|
|
|_______ ASCII text: "DNASP003 Revxxx". This is just an eye-catcher
and/or ego boost for the Echo and Nagra boys. It's the
ROM version and EEPROM revision level of the firmware in
the CAM.

nn
|_____________ Checksum (all other bytes XORed together)


Just for the sake of completeness, the ATR from a ROM2-based card looks like
this:

3F ... Convention definition
|
|_____________ Inverse convention (data is inverted)

FF 95 00 FF 91 ... Initial parm setup
| | | | |
| | | | |_ Td1=91 (Ta2 and Td2 will be sent, Protocol is async
| | | | half duplex block format)
| | | |____ Tc1=FF (G-uard time=257 bits)
| | |_______ Tb1=00 (No Vpp)
| |__________ Ta1=95 (F=512, D=16; Bit period=(512/16) (32) clocks)
|_____________ T0=FF (Ta1, Tb1, Tc1, and Td1 will be sent, 15
historical characters will be sent)

81 71 ... Secondary parameters
| |
| |__________ Td2=71 (Ta3, Tb3, and Tc3 will be sent, protocol is async
| half duplex block format)
|_____________ Ta2=81 (Mode change not allowed, Protocol is async half
duplex block format)

60 47 00 ... T=1 specific parameters
| | |
| | |_______ Tc3=00 (LRC (XOR-type) error checking to be used)
| |__________ Tb3=47 (Char wait time is 25 bit times, block wait time
| is 634.9 mSec + 11 bit times) (1 bit time=7.111
| uSec)
|_____________ Ta3=60 (Receive block size=0x60 bytes (96 bytes decimal)

44 4E 41 53 50 30 30 32 20 52 65 76 30 35 32 ... Historical bytes
| |
|_____ ___________________________________|
|
|_______ ASCII text: "DNASP002 Rev052". This is just an eye-catcher
and/or ego boost for the Echo and Nagra boys. It's the
ROM version and EEPROM revision level of the firmware in
the CAM. Note ROM version 2. Also note that all ROM2s
will probably say "Rev052" because there's no more room
in their EEPROM for updates, so they're basically stuck
at rev 052 forever.

nn
|_____________ Checksum (all other bytes XORed together)

The data format (the T=1 format) is selected by bytes Td1, Td2, and Ta2.
Note that all of them agree that the data format is asynchronous half-duplex
block transfer. The baud rate is defined by byte Ta1. The upper nibble of
this byte defines parameter F (frequency) as being 512, while the lower nibble
defines parameter D (divisor) as being 16. The bit rate is found by dividing
the card's input clock frequency by the quantity (F/D) (in the case of
NagraVision cards, F/D = 512/16 = 32). If we check the clock being fed to the
smartcard by an EchoStar IRD, we find that the master clock frequency, f, is
either 4.5 MHz or 4.0 MHz, depending on the model IRD being used. Thus, the
final baud rate for communication between an EchoStar IRD and smartcard is
4,500,000/32 (140,625) bps, or 4,000,000/32 (125,000) bps . Note that this
bit rate is only necessarily 140,625 bps when the card is in an EchoStar IRD.
If the card is in a programmer that feeds a 3.6864 MHz clock to the card, the
final baud rate will be 115,200 bps (though the ATR baud rate will become
9909 bps).
The parameters such as "guard time", "character wait time", and "block wait
time" apply only to messages being sent to the card from the IRD. These
delays exist to allow the card enough time to move received data into its
internal buffers and perform any necessary decryption on the received data
before the next byte is received. It is assumed that the master device will
not need such delays, since the master device most likely has a great deal
more processing horsepower than the smartcard. In the case of the NagraVision
smartcard, a delay of at least 25 bit times (178 microseconds) is required
between bytes, and a delay of at least 635 milliseconds is required between
whole blocks.
The Tc3 byte specifies that the card is going to use LRC (Longitudinal
Redundancy Checking) as its means of error correction. This means that for
any message sent, the final byte of the message will be the XOR-sum of all
of the other bytes in the message. The other possibility for error checking
(which is required by the ISO-7816 spec) is CRC checking, which would be
selected if Tc3 was equal to 1.
The Ta3 byte specifies that the maximum message size that the card can
accept it 0x64 (100 decimal) bytes. If the receiver wants to send a message
that's longer than this, it has to break it up into smaller packets. In
NagraVision ROM version 1 cards, Ta3 was 0x60 (96 decimal). One interesting
thing to note, however, is that the first thing most IRDs I've seen do after
they reset the smartcard is request that the smartcard shrink its buffer size
to 0x58 (88 decimal) bytes.
The historical bytes are really nothing more than superfluous identification
bytes that are used by the master device to learn additional information
about the smartcard. In this case, the card sends ASCII text indicating
that it is a Nagra/Dish Network smartcard, ("DNASP"), with ROM version 3
("003"), and its current EEPROM code revision ("Revxxx"). As of this
writing, the current smartcard EEPROM revision level for EchoStar ROM3
smartcards is 372, so this text will probably read "Rev372".
Finally, the ATR is terminated by a checksum, which is the XOR-sum of all
of the other bytes in the ATR.

1.2- NagraVision's packet structure I: The ISO-specified portion

The T=1 protocol has a very specific format for the data packets. The
first 3 bytes of the packet, as well as the last byte (or the last two bytes
if CRC checking is used) of the packet are defined specifically as follows:

Byte 1: Node address byte (NAD)
Byte 2: Procedure control byte (PC:cool:
Byte 3: Length byte (LEN)
Last byte: Checksum (LRC)

Thus, an ISO-7816 compliant T=1 message looks like this:

NAD PCB LEN <information field> LRC

The NAD is used to route messages. The upper nibble of the NAD is defined
as the target address, and the lower nibble is defined as the source address.
In the NagraVision system, only two addresses are defined: Address 1 is the
receiver, and address 2 is the smartcard. Although 4 bits appear to be
available for addressing, in reality, only the lower 3 bits of each nibble
are available for addresses. The upper bit of each nibble is reserved for
Vpp control requests. Since the NagraVision system doesn't use these bits,
they won't be discussed here. Actually, it's also interesting to note that
the smartcarts don't do any sanity checking on the NAD...they just assume that
whatever NAD they received was the correct one and swap its nibbles when they
send a response.
The PCB is used to identify what type of data is being sent, whether it's
part of a block that's been broken up due to buffer size restrictions, if
it's a special type of control request, and so forth. There are 3 basic
formats for the PCB, as follows:

A standard "instruction" block has a PCB that looks like this:

% 0 N C 0 0 0 0 0
| | |
| | |____________ "Chain" bit. If this bit is set, it means that this
| | packet requires at least one more packet before the
| | entire message is considered "sent".
| |______________ "sequence Number" bit. This bit should toggle between
| messages. It's used to help ensure that packets were
| not missed if the chain bit is set...if the smartcard
| misses a single packet (or any odd number of packets)
| from the master, it will know that data is corrupt.
|________________ "0" in bit 7 indicates "instruction block".

A standard ISO 7816 T=1 response block from will have a PCB like this:

% 1 0 0 N 0 0 O E
|_| | | |__ Errors detected either in LRC byte or in parity.
| | |____ Other errors occurred
| |__________ "sequence Number" bit. This bit should match the N
| bit for the message to which the smartcard is
| responding.
|_______________ "10" in bits 7-6 indicates "response block"

One would ordinarily expect that the CAM responses would be sent in a
response block as defined by the ISO 7816 T=1 spec, but it turns out that
for the most part, when the CAM responds, it responds with an instruction
block of its own. And as if that deviation from the ISO spec weren't enough,
the CAM's instruction block responses don't have INS, CLA, P1, P2, or P3
bytes at the start of the information field (though the IRD's messages do).
Very odd.

Note that if a command is sent with an incorrect checksum, the CAM will
respond with one of the following messages:

12 81 00 93 -or-
12 91 00 83
| | | |_ Checksum
| | |____ Info field size (no data in this response)
| |_______ Error response: Parity/LRC error
|__________ NAD

This is an indication of an error condition either in the LRC or a parity
error with one of the bytes of the message.

Other control requests all follow a common format as follows:

% 1 1 R 0 0 0 T T
|_| | |_|
| | |___ Request type as follows:
| | 00=Resync (complete reset)
| | 01=IFS (Information Field Size)
| | 10=Abort
| | 11=WTX (Wait time)
| |____________ Request/Response (0=request, 1=response)
|_______________ "11" in bits 7-6 indicates "control request"

For an IFS request, a single byte of data will be included that tells the
target what size the source would like it to change its IFS to. Note that
although it is theoretically possible to request that the card change its IFS
to a value larger than the one specified in the ATR, the target would probably
not respond favorably to such a request. A sample IFS request (taken from an
EchoStar log) might look like this:

21 C1 01 58 89 Receiver requests card change its IFS to 0x58 bytes
12 E1 01 58 AA Card acknowledges request
|
|________ Requested IFS

Note that it is necessary to command the card to adjust its IFS after
resetting it, since the NagraVision cards default their IFS to $20 when
they are reset. As a result, any commands whose response is > $20 bytes
either have deal with a response that is chained, or the IFS has to be
adjusted upwards. Note that the cards don't do any sort of sanity checking
against the IFS on received messages. Oops.

For a WTX request, a single byte of data will be included that tells the
target what new value the source would like it to use as a block wait time
when the target is sending data to the source. This value is a multiple of
the Block Wait Time (BWT) specified by the source in its ATR.

The LEN byte is fairly straightforward: It specifies the total number of
bytes to be included in the information field.
The LRC byte is the checksum for the message. Note that this can either be
an LRC (which is what NagraVision uses) or a CRC.

1.2.1- Chained messages

When chained messages are used (either from the IRD to the CAM or from the
CAM to the IRD), the device receiving the split-up message must return a
response block to the sending device indicating that it received each block of
data correctly, so that the sending device knows that it's okay to move on to
the next block of data. The response block that must be sent depends on the
NAD and PCB of the message being ACKed, as follows:

NAD and PCB of source message Response message
----------------------------- --------------------------------
21 20 12 80 00 92
21 60 12 90 00 82
12 20 21 80 00 A1
12 60 21 90 00 B1

If the receiving device sends a response whose PCB indicates that an error
of some sort was detected, the sending device will resend the block that was
in error. If the receiving device sends some message that performs a request
of any kind, it can expect the sending device to abort the remainder of the
transmission and respond to its request.
 
K

kalamar

Guest
#5
A conditional access system comprises a combination of scrambling and encryption to prevent unauthorised reception. Encryption is the process of protecting the secret keys that are transmitted with a scrambled signal to enable the descrambler to work. The scrambler key, called the control word must, of course, be sent to the receiver in encrypted form as an entitlement control message (ECM). The CA subsystem in the receiver will decrypt the control word only when authorised to do so; that authority is sent to the receiver in the form of an entitlement management message (EMM). This layered approach is fundamental to all proprietry CA systems in use today.



The control word is changed at intervals of 10 seconds, typically. The ECM, sometimes called the multi-session key, is changed at perhaps monthly intervals to avoid hackers gaining ground.



2. The Development of Standards
Way back in 1988, an attempt was made by France Telecom and others to develop a standard encryption system for europe. The result was Eurocrypt. Unfortunately, in its early manifestations it was not particularly secure and multiplex operators went their own way. Thus, in 1992 when the DVB started their consideration of CA systems, they recognised that the time had passed when a single standard could realistically be agreed and settled for the still difficult task of seeking a common framework within which different systems could exist and compete.

They therefore defined an interface structure, the Common Interface, which would allow the set top box to receive signals from several service providers operating different CA systems. The common interface module contains the CA system, rather than the STB itself, if necessary allowing multiple modules to be plugged into a single STB. However, there were serious objections to the common interface from many CA suppliers on the grounds that the extra cost would be unacceptable so the DVB stopped short of mandating the Common Interface, instead recommending it, along with simulcrypt. The Common Interface was endorsed by CENELEC in May 1996 and the DTG unanimously adopted its use for digital terrestrial transmission in the UK at its meeting on 13th May 1996.

Since then the European Commission has required the use of a common interface mechanism for all integrated tv sets (excluding STBs which may employ embedded CA systems) and this is likely to be the eventual outcome - an embedded CA system in subsidised STBs and Common Interface slots in all other devices. It should be noted that the Common Interface connector allows plug-in cards for other functions besides CA; for example it is proposed to provide audio description for the visually impaired using a common interface card.

Simulcrypt allows two CA systems to work side by side, transmitting separate entitlement messages to two separate types of STU, with different CA systems. It also gives the multiplex provider the opportunity to increase his viewer base by cooperating with other multiplex operators. Technical simulcrypt is the same thing but within a single multiplex, thus giving the multiplex operator some leverage with the CA suppliers.

The simulcrypt system is shown diagramatically below. Note that it requires cooperation between CA suppliers - something which does not come naturally!



If a viewer wishes to receive services from different providers who do not simulcrypt each other's ECMs, the only option is to acquire separate decryption for each CA system. The Common Interface enables a multicrypt environment, allowing an additional CA system to be added as a module. This is not quite the panacea it seems, since it still requires the CA vendor to develop the module, something he is unlikely to be keen on if his best customer doesn't approve. In practice, the possibility of multicrypt encourages the parties to conclude a simulcrypt agreement.
 
K

kalamar

Guest
#6
STANDARD

* BISS : Basic Interoperable Scrambling System
* bslbf : Bit string, left bit first
* CA : Conditional Access
* CAT : Conditional Access Table
* CSA : (DV:cool: Common Scrambling Algorithm
* CW : Control Word
* DES : Data Encryption Standard
* DSNG : Digital Satellite News Gathering
* DVB : Digital Video Broadcasting
* ECB : Electronic Codebook
* ECM : Entitlement Control Message
* EMM : Entitlement Management Message
* ESW : Encrypted Session Word
* lsb : Least Significant Bit
* LSB : Least Significant Byte
* MC : Management Centre
* msb : Most Significant Bit
* MSB : Most Significant Byte
* PID : Packet Identification number
* PMT : Programme Map Table
* SW : Session Word
* uimsbf : Unsigned integer, most significant bit first

NON-STANDARD
(from Nagravision)
* MECM : Management Entitlement Control Message
 
K

kalamar

Guest
#8
tnx OM just some stuff from my vast archives hope it covered the subject,if not,theres a lot more where that came from. just ask and I will see if me gots it. (somewhere)
 
B

blaise10

Member
Messages
12
Likes
0
My Satellite Setup
4 X 1.8 m dishes, C &amp; Ku Band (5W, 64E, 68.5E, 72.5E, 78E)
My Location
Northern Tanzania (Kilimanjaro), East Africa
#9
Help! Is it possible to make any FTA to get those scrambled channels? I have 1 Gulf Star 9700S, FTA of course! Thanx :confused
 
N

Node

Regular Member
Messages
28
Likes
0
#10
Hi Kalamar;

This is an ATR I read off a card can you break this down for me.


ATR: 3F7F13250140B01069FF4A5001474C0000000000

Like you did.


Thanks
Node
 
Top