ISO7816 APDU和尋址偏移的最大長度？

我對ISO7816-4兼容的第一個行業間APDU感興趣。這樣一個APDU可以/可以擁有的最大長度是多少？ISO7816 APDU和尋址偏移的最大長度？

我能想到的最長APDU應的延伸長度ISO殼體4 APDU。這意味着我們有4個字節的標題，3個字節用於擴展Lc和2個字節用於擴展Le。此外，Lc字段允許處理總共2^16字節。考慮到這種最壞情況的APDU，一個2字節的大短值顯然不足以解決最後字節的偏移量。

是否有針對此問題最好的做法還是我錯過了什麼？

來源

2013-10-01 Thomas Lieven

你的計算是正確的（除了數控的最大大小以字節爲單位64Ki - 1，不64Ki。所以最大的命令APDU將4 + 3 + (64Ki - 1) + 2 = 64Ki + 8。請注意，可返回的數據量爲 64Ki，有兩個字節的狀態字，響應APDU的最大尺寸是64Ki + 2。然而，許多智能卡會限制智能卡可以發送和返回的數據量。ISO 7816-4 2013規範包含一些方法來指示「緩衝區智能卡的大小」和智能卡應用

在Java卡上的限制設置爲32起 - 1，原因很簡單，較大的值不能存儲內簽署短。需要將來自EEPROM的字節流式傳輸以獲得接近該大小的任何地方，APDU緩衝區將比這個小得多。

關於

現在我想你是在談論從智能卡中讀取文件結構「的最後一個字節偏移」。這些使用READ BINARY APDU（B0）命令讀出，該命令實際上包含P1/P2中的偏移量。用奇數INS讀取二進制數（B1）可用於高於32Ki的偏移量。通過這些命令，您可以處理大於大多數智能卡的最大內存量的文件。

這同樣適用於在UPDATE二進制命令，當然。所以在64Ki上讀寫字節不是問題。然而，確定文件大小並讀取到文件的確切末尾是比您想象的更「有趣」。

來源

2013-10-02 16:31:38

我能跟着你（64Ki - 1）-argument - LC不允許被設置爲全零。 –

至於「最後字節的偏移量」，我只是想知道如何解決例如這個大APDU的Le字段或最後Nc個字節。但是，如果卡可以限制/確定接受的APDU的大小並且甚至能夠指出這個，那麼這應該不是問題。我的混亂的部分是由於這樣的事實，ISO7816指定LC作爲短值，但被數據字段內傳輸可以是早已進入整數大小類也根據ISO7816 BER-TLV結構的長度。顯然似乎有另一種處理大型BER-TLV結構的方法。 –

TLV結構通常只對卡上的* record *結構感興趣，代表對象。此外，它們用於處理命令和響應結構本身的參數（DO）。那些通常不那麼大。文件中的TLV結構不重要。直到我認爲ISO 7816-4 2005的最大長度爲64Ki - 1。這可能已經改變，以允許更靈活地處理長度參數（在BER中，即使小長度可以由最多5個字節表示，例如8400000001是完全有效的），使用什麼取決於實現。 –

ISO7816 APDU和尋址偏移的最大長度？

回答

相關問題