基于A(yíng)ndroid的機頂盒CAS系統的開(kāi)發(fā)
加入技術(shù)交流群
2．3 智能卡任務(wù)模塊
智能卡的通信標準有T0和T1兩種，T0按字節傳送，T1按塊傳送，而在設計過(guò)程中通常支持兩種協(xié)議。一般采用I2C總線(xiàn)通信，而智能卡內部一般沒(méi)有上拉電阻，所以在電路設計過(guò)程中，SCL和SDA的引腳處必須加上拉電阻，否則無(wú)法正常通信。根據通信協(xié)議，如果要對智能卡數據讀寫(xiě)操作，首先要發(fā)送5字節的命令字，這5字節命令字依次為CLA、INS、P1、P2、P3，其中CLA為指令類(lèi)型，INS為命令符，P1、P2為操作文件位置，P3為后續字符數。智能卡接收到命令符就可以根據命令種類(lèi)對其后續數據進(jìn)行操作，同時(shí)智能卡就可以發(fā)出兩個(gè)字節W1、W2的應答符。如果成功，W1、W2分別為0x90、0x00；如果不成功則會(huì )返回相應的代碼，以便給開(kāi)發(fā)者提供調試。因為智能卡內部十分復雜，篇幅有限，所以想深入了解原理的話(huà)可以參考智能卡標準，這里僅介紹機頂盒操作智能卡過(guò)程的設計。本文引用地址：http://dyxdggzs.com/article/154097.htm
如圖6所示，在智能卡任務(wù)模塊中，在系統啟動(dòng)之初，未進(jìn)入文件系統之前，就要對智能卡進(jìn)行初始化，分配內存池，強制為智能卡復位，從而選擇通信類(lèi)型(T0或T1)，全部完成之后就可以進(jìn)入文件系統。通過(guò)CAS_CARD_TASK()為智能卡建立線(xiàn)程，在其線(xiàn)程內部使用CAS_CARD _ReceiveMessage()接收來(lái)自EMM或者ECM的命令字。如果合法，通過(guò)CAS_CARD_SendMessage()可以把應答字給其兩個(gè)模塊，同時(shí)通知其他兩個(gè)模塊發(fā)送操作數，若是EMM則到此結束，若為ECM則智能卡會(huì )把解密的CW通過(guò)CAS_CARD_SendMessage()發(fā)送給機頂盒。
2．4 其他細節設計
CAS系統除了最重要的解擾以外，還有其他重要的附屬功能，如郵件、在線(xiàn)付費、在線(xiàn)充值、節目點(diǎn)播、區域限制、用戶(hù)管理。這些信息都存儲在EMM表中，所以EMM和ECM表的解析也是一個(gè)十分重要的步驟，只有正確地提取出 EMM中的CA信息，才能順利地進(jìn)行下一步的操作。根據MPEG-2標準和PSI／SI協(xié)議，以及智能卡廠(chǎng)商的提供功能表，就能設計出EMM和ECM的解析函數。
表1列出了一個(gè)通用CA的描述符。
由于每個(gè)智能卡廠(chǎng)商的填充數據不一樣，所以必須根據廠(chǎng)商的定義再去提取數據、處理數據。由于筆者參與設計的是某公司提供的智能卡，所以數據的格式也都以它為標準。最終設計包括12個(gè)源文件、5個(gè)頭文件。
3 CAS子系統Android的移植
CAS終端子系統起初沒(méi)計由于涉及到與底層交互，采用的是C語(yǔ)言。如果想要使上層的JAVA環(huán)境調用其API，就要遵循JNI規范添加新的頭文件，使其應用層能夠方便地調用。同時(shí)Google在設計Androld之初就提供了NDK套件，有著(zhù)獨有的交叉編譯器，使得原有的許多C語(yǔ)言編寫(xiě)的驅動(dòng)、應用程序可十分方便地移植到Android系統中。
評論