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
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.