Seca Mediaguard |
|
|
View a sample communication with the Smart Card (using MKFind log). A complete overview of all Seca INS & Nanos (thanks Adrian64 my Friend). A listing of all known Seca Startup Records. Sample of a manual V6 card extraction (thanks to Kcplus and Satgirl). This is a brief overview of the Seca Mediaguard systems structure. For more detailed information you may want to download several documents from the download section. Initializing the card: The card plays a crucial role in the communication process between the CAM and the card in the sense that the card dictates how the communication should take place. Upon every reset, the card will make itself known to the receiver/CAM. A reset is triggered, the moment the receiver is turned on, but also every time the card is pulled from and then reinserted into the CAM. What happens upon a reset of the card is the following: The card will tell to the receiver how it needs to be updated. This notification to the CAM is defined in the ISO7816-3 specifications and it is very strict. The information, according to the ISO protocol, contains for instance the specification what Voltage and Amperage are needed to update the card. But it will also tell the CAM at what Baudrate and whether the communication should be synchronous or asynchronous etc. The Seca Mediaguard algorithm: The Seca Mediaguard algorithm is based on a 8 byte long coded key; the so called Crypted Controlword. From this Crypted Controlword, the Decypted Controlword is computed. For that computation, a 16 byte key is needed. The 16 byte key is composed of 2 8 byte keys, called the Primary Key (PK) and the Secundary Key (SK) respectively. Then there are 2 more important sets of keys to be mentioned: The Operational Keys (OK) and the Management Keys (MK). The OK are the actual keys that will open up your channel. The MK are the keys that will make your OK change automatically when the provider sends the necessary signal. Then, last but not least, we need to mention the Provider Keys and the Seca Keys: Provider Keys are those keys that enable the provider to activate, modify or disable a card. But only operations within 1 provider are possible with those keys. The Seca Keys are the keys that authorize adjustments to a card on all levels. So with the right Seca Keys, it is possible to even add or remove providers, not just modify them. How does the communication work: When the communication protocol of the card is known to the CAM, the CAM will start giving instructions and asking information. The instructions that the CAM will send to the card, are called Instruction Bytes or INS for short. A very comprehensive listing of all INS is to be found in the download section (Seca FAQ Duits.zip), but it is in German. Not quite as comprehensive but good for starters is the English document in the download section, called Mediaguard Musings Engels.zip. As mentioned above, the card will start sending information to the CAM upon reset. The message it sends is called the ATR which is short for Answer To Reset. As soon as the ATR is received by the CAM, the CAM will start requesting information from the card. That can be information about which providers are supported by the card, what authorization does the user have for a selected provider etc. etc. Let's give an example of such a communication: One of the requests a CAM will make for instance is the request for information about supported providers. The INS for requesting provider info is 12 (hex). The standard notation for hex is 0x. So hex 12 will be written as 0x12. The complete syntax for Seca Instruction 12 (or INS 12) would be 12: C1 12 xx 00 yywhere: - C1 12 means INS 0x12 - xxis the provider number for which the information is requested. 00 is SECA. - yyis the number of bytes the answer should contain. C1 12 00 00 19 C1 12 00 00 19 12 00 00 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 2000 00 00 00 00 00 0090 00 So how will the card respond: Syntax for the answer is: 12 bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 00 dd dd ee ff ff 90 00 where: - 12 is the INS identification for the answer. (in other words, it says "this is an answer to request 12). - the 90 00 at the end of the string is standard Seca and means "everything is OK". - in between there are exactly the number of bytes as specified in the INS (so yy bytes, see above) - bb bbis the Provider ID. - cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ccis the Provider name. - dd ddis the Smartcard Address. - eeis yet unknown. - ff ffcontains the end-date of the subscription. So, the the following INS: C1 12 01 00 19 would mean: - give me information about the first provider in the list - and make sure the answer contains 25 bytes (19 hex). The answer to that would be: 12 00 04 43 41 4E 41 4C 53 41 54 45 4C 4C 49 54 45 20 20 00 FF FF FF 0B CF 90 00 which means: - answer to INS 0x12 is - Prov.ID is 00 04 - Name is CANALSATELLITE - Smartcard Address is FF FF - Subscription ends on 31.12.2001 Well, that should be enough to give you some idea as to how Seca communication is structured. It will probably give you an idea of what interesting stuff there is to learn about those small cards. For a nice example of how a Seca instruction is executed, you can have a look in the software chapter. There you'll find a page called MOSC cloning. At the end of that page there is an example of a Seca INS to change the cards serial number. OK, have fun :-)) View a sample communication with the Smart Card (using MKFind log). | |