Develop smart card CA application on the base of NGB standard interface - 泰信论坛

The development of smart card CA application on the base of NGB standard interface is the research of smart card CA, as for the traditional CA used smart card,on the condition of current STB technology platform,if it is possible that we can develop the current STB client terminal software into a commonly multi-platform APK according to the NGB Java interface specification of NGB, and thus the traditionally closed smart card CA system can be compatibility to DCAS. the development measures of smart card CA application is some kind of the same as DCAS application, you can read the last post of 《The development of DCAS application on the base of NGB standard interface》. Now we just tell the differences of them.

The key difference between them is the smart card communication, including the reset, initiation of smart card, CA information acquisition, the ECM and EMM data decryption and STB & SC Binding, etc. DTVOS extends the interface of smart devices according to the NGB standard interface, and through the device interface combining the communication protocol of different CA, such as wether applying protocol T0, T1 or T14, the order’s form, the packaging measure, the smart card’s response time after receiving the order,the response form, etc,and thus it can accomplish the smart card communication function of traditional CA base in CA application.

In addition, there is another difference between the development of traditional smart card CA application and DCAS and that is the set of CW. Because the DCAS uses hierarchy key system, we set the encrypted CW when setting CW, and at the same time we set various encrypted hierarchy key. But as for the current smart card CA is short of the system, there is a difference when setting CW. According to the CW interface given by the specification which is: loadCW,

The way can be used to inform the terminal software platform to insert control word to the descrambler, and insert the needed key to the terminal security chip.

And for @param cwKey control word, if the control word is plaintext, the LevelKeys parameter being ignored. And if the cwKey is null, that means the CA application doesn’t provide the valid control word.

@param levelKeys is the multilevel key imbedding in the terminal security chip. The key group’s index is equal to the absolute position of terminal security chip, in the group the special element value is null, which indicates that the key shouldn’t be insert into the specified position in the terminal security chip.
@param schemeId the schemeId is used to the specified terminal security chip’s encryption algorithm (such as AES, TDES)
@ChipController interface giving the scheme list. If the controller only support one form then the scheme value should be ignored.

If we take no account of advanced security environment, after the smart card decoding the cw, the setting cw is set when the control word is plaintext, referring to the conception of CWKey.
public class CWKey extends Key
{
public static final int PARITY_EVEN = 0;
public static final int PARITY_ODD = 1;

/*
*@param value key value

*@param true-value indicates the key is encrypted and false value means the key is unencrypted.
*@param odd-even value, indicating the parity of the control word.
*/
public CWKey(byte[] value, boolean encrypted, int parity)

/**
*return to the control word’s parity
*@return control word’s parity
*/
public int getParity()

}

ECW[1]=new CWKey (oddcw, false, 1);
try {
         descramblerContext.loadCW(0x1234, ECW [0], null,  ChipController.SCHEME_3DES);
         } catch (CADriverException ex) {
}

try {
         descramblerContext.loadCW(0x1234, ECW [1], null,  ChipController.SCHEME_3DES);
         } catch (CADriverException ex) {
}

After we finished the two programs according to the case of DCAS application development, it is relatively easy to develop a commonly used smart card CA application.

Each CA is a individual application, namely a APK file, which has its own interface. CA application uses Android application’s basic module namely service to manage its own life cycle. It monitors the Android. Intent. Action. BOOT_COMPLETED broadcast and start its service after broadcast, and then accomplishing the functions like startXlet when starting service:finishing its own initiation (including smart card’s initiation), accomplishing the sign to CASModuleManager when the descramble works. The sign process is as follows:

As shown below, when the STB finding the current program is scrambled, the platform will call the startDescrambling of CASModuleManager, to pass the systemid and sign as CASEventListener to monior the returning of descrambling result. When calling the startDescrambling interface of CA application, it will start to receive ECM, EMM data. After licensed and the cw descrambled, we can call loadCW interface to set control word to descramble the programs. Please sign in www.interactiveweb.org, to learn the detailed courses and cases. If you want to learn the davic interface quickly, please visit www.code4tv.com, where there is the sealed mhp whole interface.