擴展長度不適用於T = 1

我試圖從JC 2.2.2卡發送數據文件到主機應用程序。所有文件都小於256字節。但是數據需要加密和簽名（用於安全消息），如下所示。將MAC添加到加密數據後，某些文件的長度會超過256個字節。但我使用擴展長度，所以我認爲一次發送超過256個字節沒有問題。如果結果密碼加上MAC小於256字節，程序工作正常。以下是一段將響應apdu發送給主機的代碼。擴展長度不適用於T = 1

Util.arrayCopyNonAtomic(file, offset, buffer, (short)0, file.length);        
respLength = secureCrypto.wrapResponseAPDU(ssc, apdu, buffOfset, file.length); 
apdu.setOutgoing(); 
apdu.setOutgoingLength(respLength);   // 0x6F00 error occurs during the execution of this line 
apdu.sendBytesLong(buffer, (short)0, respLength);

卡詳細信息：

Terminal found : 2 
PC/SC terminal OMNIKEY CardMan 5x21 0 
PC/SC terminal OMNIKEY CardMan 5x21-CL 0 
ATR: 13 bytes 
Card Info : PC/SC card in OMNIKEY CardMan 5x21-CL 0, protocol T=1, state OK

在主機端，我得到0x6F00錯誤代碼。我追蹤了程序，發現在執行apdu.setOutgoingLenght（respLength）期間發生錯誤。另外我的applet類實現了ExtendedLength接口。任何有用的信息請

來源

2013-04-23 ally

您確定該卡支持擴展長度的APDU嗎？你是否發送了命令，它是由你的代碼以擴展長度的APDU格式實現的？ – guidot 2013-04-24 07:47:44

對於你的第一個問題，我會說是，因爲我使用JC 2.2.2和T = 1協議。對於第二個問題，我不確定，我不知道我是否必須做這樣的事情。請給我一個擴展長度格式化的APDU的例子，你會更有幫助嗎？ – ally 2013-04-24 08:40:55

我只能參考ISO 7816第4部分，它描述了字節格式。 LC的第一個字節爲零的3字節規範表示擴展長度的LC字段，這也要求LE字段的擴展格式爲2字節）。在沒有LC的情況下，LE規範具有額外的前導零字節，接着是兩個字節長度。如果你給你的應用程序語言和使用的API可能是別人可以幫助你進一步。 – guidot 2013-04-24 10:28:27

你也許忘了實施javacardx.apdu.ExtendedLength「標記」接口爲您的課程擴展Applet類？請注意，該卡應支持此功能（它位於javacardx名稱空間中，而不是javacard）。此外，爲了使讀卡器正確操作，卡應指示讀卡器的延長長度支持（使用ISO 14443 B型非接觸式接口的ATR或EF.ATR）。

即使該卡支持擴展長度，也可能需要多次撥打sendBytesLong()。擴展長度可達64KiB（Java Card只能達到規範之外的32KiB，至少對於命令APDU來說），但是如果它們存在的話，將會有很少的卡片爲APDU運行64KiB的RAM緩衝。

最後，APDU的可以延長或不延長。這意味着APDU命令以及APDU響應都必須是正常的或擴展長度的APDU。由於它們不包含命令或響應數據，因此只有ISO第1類APDU纔可以免除。否則，Nc（在ISO 7816-4中稱爲Lc）和Ne（在ISO標準中稱爲Le）的編碼都必須使用擴展長度編碼。換句話說，第一個編碼必須是3字節長，第一個編碼爲00，第二個編碼（如果存在的話，對於ISO 4型APDU）必須是兩個字節大小。

請注意javax.smartcardio處理擴展長度的APDU非常優雅。不幸的是，讀卡器中的所有擴展功能都不是很好的編程。由於您使用的是Omnikey閱讀器，因此您應該從閱讀器 .dll的擴展長度錯誤相對安全。

來源

2013-04-25 20:13:20

我的答案Ally中有任何遺漏嗎？ – 2013-05-05 09:20:51

通過回答密碼問題，我已經獲得了超過10K的分數，這真是太神奇了，因爲這根本不會產生任何分數。 – 2013-05-12 21:36:54

+1，現在它確實;-) – 2013-06-24 08:00:13

擴展長度不適用於T = 1

回答

相關問題