需要有關加密算法的建議

Question

為這個問題的論文性質道歉。 我一直在努力解決這個問題，並試圖用我具體的問題總結我對所需內容的理解。

在這個有關從歐洲DTCO公司卡讀取數據的問題中 ，我得到的建議涉及下面的截圖中的算法（來自本文件的附錄11），但我不清楚如何執行兩個突出顯示的步驟。

1. 我看到Sign是包含證書的數組的一部分，但用公鑰打開它意味着什么？ 我可以通過從卡中讀取CA_Certificate並使用CAR發出管理安全環境 APDU （參見算法的第一步）來成功執行該步驟。 但是，通過這種方式選擇了公鑰，我在開放的Sign步驟中使用了哪些公鑰。 MSE選擇一個，但我沒有; 我只有來自ERCA的歐洲公鑰，但是我在卡中選擇了相同的密鑰嗎？ 我沒有任何私鑰，但我需要它們。

2. 在檢查Hash（C'）= H'的步驟中 ，我應該如何計算哈希？ 進行加密/解密/散列似乎有很多不同的方式（格式正確嗎？）我很困惑。

我真正需要能夠讀取我需要的數據是使用EXTERNAL AUTHENTICATE進行身份驗證 ，緊接在返回8字節質詢的GET CHALLENGE之后。 我認為我需要用它來計算EXTERNAL AUTHENTICATE的密碼。 我在下面找到了示例代碼（ 請參閱完整帖子 ），雖然它看起來像是某種類似C語言的腳本語言（我正在使用C＃），但對於不同類型的智能卡，它似乎與我必須使用的非常類似。

//
// Authenticate against CardOS card
//

var card = new Card(_scsh3.reader);
var crypto = new Crypto();

var key = new Key();
key.setComponent(Key.DES,
    new ByteString("01010101010101010101010101010101", HEX));

// Get challenge
var challenge = card.sendApdu(0x00, 0x84, 0x00, 0x00, 8, [0x9000]);

// Crypto.DES_MAC_EMV is a CBC generated Retail-MAC
var cipher = crypto.sign(key, Crypto.DES_MAC_EMV, challenge);

card.sendApdu(0x00, 0x82, 0x00, 0x81, cipher);

print("Card returns " + card.SW.toString(16) + " - " + card.SWMSG);

差異是

1. 附加的P2參數表明已經完成了管理安全環境，可能是使用了來自Card_Certificate的CAR '，這對我來說不起作用，盡管它與來自CA_Certificate的CAR '有關。

2. Lc為0x80而不是示例代碼中的0x81。

3. 我計算在這里使用的任何密碼都必須是128個字節長，而不清楚樣本中的密碼長度。

Answer 1

不要自己這樣做，很多事情都可能出錯。 充氣城堡加密庫確實支持ISO 9706-2簽名。 它適用於c＃和java。

一開始這個文件清楚怎么回事。 最初從卡片上取回的是

x_c = sign || c_n || c_ar 

Sign是消息上編碼/填充/散列函數輸出的RSA簽名（在這種情況下，消息是證書）。 c_n是消息的其余部分，c_ar是創建簽名標志的證書頒發機構的標識符。

使用的編碼函數是μ（m）= 6A || m [1] || hash（m）|| BC

在哪里|| 是串聯，6A只是字節0x6A，同樣是0xBC。 散列是一些散列函數，m 1是散列函數的第一個k長度 - 消息的16位。 m [2]然后是消息的其余部分，什么存儲為c_n。

DES不是在這里開發的。

你應該在這做什么

1. 通過連接\\ m 1和c_n獲取消息/證書
2. 計算μ（m [1] || c_n）
3. 通過c_ar中指示的證書頒發機構驗證sign是μ（m [1] || c_n）上的rsa簽名

Answer 2

這個答案也有點冗長，因為必須解釋誤解。 上面的文字摘錄涉及非對稱密鑰對的認證。 由於除了擁有公鑰的私人對抗之外什么都不能證明，因此需要額外的憑證。 證書的頒發者通常聲稱已經驗證了您的身份，並且證書的簽名證明了這一點（簽名僅在發行人的公鑰在互聯網上眾所周知或因為它已經存儲在卡上時才有用）。 通常，智能卡在“驗證證書”模式下提供“執行安全操作”命令，用於此目的：它驗證發行者的簽名，解包證書中包含的公鑰或與其一起交付的公鑰，並保留它以反轉私有關鍵操作假設很快就會出現。

您的代碼段通過對稱密鑰（也稱為密鑰）處理身份驗證。 假設這個秘密僅由授權人員知道。 您認為是LC的0x81實際上是P2，意味着“請使用本地密鑰＃1”來驗證使用此密鑰的MAC計算。 事實上，采用8字節隨機數作為計算（零售或其他）MAC的輸入通常（即應用標准填充方案）導致16字節結果。 順便說一句，示例中的DES密鑰非常糟糕。 每個字節的最低有效位是奇偶校驗位，因此密鑰僅由零字節組成。

除了以某種方式進行身份驗證之外，這兩種方案都沒有任何共同點。

有關詳細信息，請參閱ISO 7816-8（用於執行安全操作），ISO 7816-4（用於外部驗證，獲取質詢和大多數其他智能卡命令）。 如果不花錢，這些很難得到 - 可能會在www上找到舊版本 - 並且讀起來很難讀，也很難理解。 Rankl / Effing“Handbuch der Chipkarten”中有更多解釋，但有時會報道英文翻譯“智能卡手冊”是特殊的。 對於證書材料，我建議使用Schneier，Applied Cryptography，它還有數百個參考資料。