智能卡安全機制比較系列（一）CardOS

文章出處：http://hz-huyue.com 作者： 人氣： 發表時間：2012年02月26日

    自從智能卡開始進入人們的日常生活之后，大家對于智能卡的安全性普遍看好，但是不同公司的智能卡在安全機制的實現方面也存在很多的差異。對于智能卡應用開發和智能卡COS設計人員來說，如果能夠更多地了解不同公司的智能卡安全機制，無疑會對自己的開發過程有所幫助。在此將逐步介紹一些流行的智能卡操作系統中各具特色的安全機制，究竟這些安全機制孰優孰劣，其實無關緊要，只要這種安全機制能夠滿足系統的安全需求就足夠了。

    首先看看早期的CardOS，CardOS是西門子公司基于自己的44C40/80系列芯片而設計的，該系列芯片RAM大小256字節，程序空間8K/16K，數據空間4K/8K，采用西門子的8051內核。CardOS在1995年推出了1.2版本，主要的APDU命令是符合ISO7816-4的文件讀寫操作，采用的安全機制非常靈活，初看起來也有點復雜，但是實際原理卻是比較簡單的。雖然目前國內市場上幾乎已經沒有什么CardOS產品了，但是了解這個初期的鼻祖級的智能卡安全機制，對于了解目前市場上流行的COS安全機制應該會有些幫助。

    CardOS采用半字節作為安全狀態，除卻0和F之外，還有1到E共計14種狀態，每個狀態分別對應要達到該狀態需要進行的某種安全認證操作以及這些認證的不同組合方式，這些安全認證包括校驗PIN或者是C/R （Challenge / Response） 認證（也就是我們現在通常所說的外部認證），而認證的組合方式包括“邏輯與”及“邏輯或”。

    對于文件的操作和密鑰的使用可以定義不同的安全狀態，只有滿足定義的安全狀態后才能進行相應的文件操作，或者密鑰的使用。無論是DF還是EF都有一組3字節的安全狀態控制字，每半字節作為一種訪問控制的狀態標識，分別對應著文件的建立、刪除、添加、讀取、更新等操作。

    這些安全狀態及其需要的認證或組合全部保存在一個特殊的內部文件STCF（Security Test Control File）安全認證控制文件中，該文件是一個TLV（Tag Length Value）結構的記錄文件，其中第一個字節就是1-E這14個狀態中的一個作為TAG，Length根據認證方式的不同而存在差別，Value當中的第一個字節表示認證類型，從中可以看出這個認證是需要PIN認證，還是需要C/R認證，或者是某幾個認證狀態的“邏輯與”及“邏輯或”組合。對于PIN認證還可以指出應該使用哪個PIN文件中的哪個PIN，同樣對于C/R認證也可以指出應該使用哪個密鑰文件中的哪個密鑰。在CardOS的系統中有一個安全狀態bit mask標志，用不同的數據位來記錄哪個安全狀態經過認證得到了滿足。在有些情況下，進行DF選擇之后，當前DF的認證狀態的bit mask標志將會被清空。

    關于“邏輯與”和“邏輯或”其實也很簡單。比如“03”的狀態表示認證第3個PIN文件中的第2個PIN，“0B”的狀態表示需要對第1個密鑰文件的第5條密鑰進行C/R認證。那么我們可以定義狀態“06”表示“03”和“0B”的邏輯或組合，定義狀態“07”表示“03”和“0B”的邏輯與組合。我們假設有兩個文件EF01和EF02，其中EF01讀寫的安全狀態分別為“03”和“06”，EF02讀寫的安全狀態分別為“0B”和“07”。那么在驗證了第3個PIN文件中的第2個PIN后，即可以讀EF01也可以寫EF01，而對于第一個密鑰文件的第5條密鑰經過C/R認證后，也可以寫EF01。對于EF02的寫操作必須同時滿足以上兩個認證狀態，對于EF02的讀則只需要C/R認證第1個密鑰文件的第5條密鑰即可。

    除了以上的安全狀態控制機制之外，CardOS還定義了所謂的線路保護LINE PROTECTION，在文件的創建過程中會定義LPROTF字段，作為線路保護屬性，有兩種線路保護模式分別為MAC方式和加密方式，同時還定義了線路保護的方向，即從卡到終端以及從終端到卡。而用來進行線路保護的密鑰只能存儲在SKF（System Key File）系統密鑰文件中。

    在CardOS中定義了幾個默認的EF文件標識，分別為：0000 = ATR二進制文件，0001 = STCF記錄文件，0002 = PIN記錄文件，0003 = SKF系統密鑰記錄文件，0004 = RSF 隨機數種子二進制文件。CardOS支持最多6層DF文件結構，可以通過文件名、文件標識、文件路徑等方式進行文件的選擇。