标签: javacard

我通过 opensc-tool将80 50 00 00 08 00 00 00 00 00 00 00 00[ INITILIZE UPDATE Command] 发送到我的 java 卡，并从卡接收00 00 11 60 01 00 8A 79 0A F9 FF 02 00 11 79 11 36 5D 71 00 A5 A5 EC 63 BB DC 05 CC[ Init Response ] 作为其响应。

正如你看到的：

在命令中，我00 00 00 00 00 00 00 00作为Host Challenge发送，并在响应中：

00 00 11 60 01 00 8A 79 0A F9= …

我搜索了 NFC SIM 卡，并在这里和那里找到了关于它们的解释：

对于那些想要使用近场通信技术但目前没有兼容 NFC 的智能手机的人，还有其他方法可以在您的手机上启用 NFC，而无需将其换成昂贵的新型号。SIM 卡和 SD 卡都可以配备 NFC 芯片，一些公司目前提供或准备提供这些选项，以便更多客户可以开始使用 NFC 技术。

我现在的问题是：

1. NFC SIM 卡是否也有内置天线，或者手机必须为 NFC SIM 本身提供 NFC 天线？
2. 如果NFC SIM没有内置天线并且手机需要为SIM提供天线，（这意味着手机必须兼容NFC，对吗？）为什么我们需要NFC SIM？难道我们不能简单地用手机的NFC芯片代替SIM卡的NFC芯片。
3. 换句话说，有没有手机外面有NFC天线，但没有NFC芯片？或者有什么方法可以在旧手机上添加天线以便在其中使用 NFC SIM？

无论如何，假设我想在我的 SIM 卡上安装以下小程序（其源代码）：

import sim.toolkit.ToolkitInterface;
import sim.toolkit.ToolkitRegistry;
...
import javacard.framework.ISOException;

public class STKTest extends Applet implements ToolkitInterface {

public static void install(byte[] bArray, short bOffset, byte bLength) {
    // GP-compliant JavaCard applet registration
    new STKTest().register(bArray, (short) (bOffset + 1), bArray[bOffset]);
}
//this method handles standard APDU …

我想在Java Card上优化SHA-3算法.我需要一个消耗更少内存的快速算法,这样可以轻松转换byte[]为short[](或缩短[]为byte[]).我目前的实现如下:

private short[] byteToShort(byte[] b,int len)
{
    short len_conv  = (short)(len/2);
    for ( short x = 0; x < len_conv;x++)
    {
        for ( short j = 0 ; j < 2 ; j++)
            aux[j] = b[2*x+j];
        temp_conv[x] = (short)((((short)aux[1]) & 0xFF) | ((((short)(aux[0]) & 0xFF) << 8 )));
    }
    return temp_conv;
}

其中len是b数组的实际大小,aux并且temp_conv被定义为private并分配为:

short[] temp_conv = JCSystem.makeTransientShortArray((short)255,JCSystem.CLEAR_ON_DESELECT); // used during conversion
byte[] aux …

我制作了一个测试小程序并用卡锁私钥安装它.

Jcop插件返回如下 -

Card Manager AID   :  A000000151000000
Card Manager state :  INITIALIZED

    Application:  SELECTABLE (---L----) A0A1A2A3A4A5A6 

即应用程序具有卡锁私钥.

我锁定卡的applet代码如下: -

boolean check = GPSystem.lockCard();
                if(check == true)
                    ISOException.throwIt((short)0x6308);
                else
                    ISOException.throwIt((short)0x6309);
                break;

这总是返回0x6309,我把这段代码放在Select文件INS中,

??>  /send 00a40000023f00
 => 00 A4 00 00 02 3F 00                               .....?.
 (55766 usec)
 <= 63 09                                              c.
Status: 0x6309

任何建议为什么这个代码没有锁定卡？

=====更新1 ==============

Card Manager AID   :  A000000151000000
Card Manager state :  INITIALIZED

    Application:  SELECTABLE (---L----) A0A1A2A3A4A5A6  
??>  /select a000000151000000 
 => 00 A4 04 00 08 A0 00 …

我想提供一个 JavaCard，以便它只允许安装由某个密钥签名的小程序。我不确定这个签名是否是 cap 文件格式的一部分。我已经可以通过从 GlobalPlatformPro 获取的代码从 Android 设备安装 cap 文件。GlobalPlatformPro README ( https://github.com/martinpaljak/GlobalPlatformPro/blob/master/README.md ) 提到了应用程序签名。但我不确定这是完成我需要做的事情的方法。我什至不确定这是可能的。

1. 我如何准备一张只允许安装已签名的 cap 文件的卡？
2. 如何创建这样的 cap 文件？

我已经可以用某个密钥锁定卡，然后安装任何cap文件都需要这个密钥。但这意味着我需要将密钥与 cap 文件一起分发，以便可以安装它。这不是一个选项，因为它会破坏密钥。

非接触式读卡器和接触式读卡器上同一张卡的ATS和应该相同吗？双接口卡上的 JavaCard 应用程序是否会做出不同的响应并影响该小程序的执行？ATRATSATR

这里还有另一个问题：接触式卡和非接触式（RF）卡之间的差异似乎表明如果它们使用相同的传输协议，它们可以是相同的。

举一个具体的例子，我有一个 JavaCard J3H145，它pcsc_scan在非接触式读卡器和接触式读卡器上提供不同的 ATR（通过 显示）。这是否意味着阅读器正在自行执行某些操作（Identiv 3700f）？我有几个 javacard 小程序，可以通过接触方式工作，但不能通过非接触方式工作。当我追踪 ADPU 的pcscd所有内容时Attempting PTS to T=1（这是否需要读者翻译T=CL？）。

^{编辑：额外研究}

有一些相关的问题开始讲述这个故事：

1. 从 ATR 确定卡类型

ATR详细说明了和ATQ-A之间的转换过程ATQ-B，而

2. 根据接口的不同，智能卡具有不同的历史字节
3. 如何更改小程序的权限和卡历史字节？

显示历史字节可以从 GP API 更改（因此ATS/ATR是可编辑的），所以我假设有一种方法可以手动修复它们。

我也在 PN532 屏蔽上测试了 J3H145（测试我的特定阅读器翻译），并且我得到了看似被截断ATR: 3B 80 80 01 01 (ISO 14443 Type B without historical bytes)和过度接触的信息（当一切正常时！）ATR: 3B DC 18 …

我有一个空的 Javacard，如下所示：

user@system$ java -jar gp.jar --list
ISD: A000000003000000 (OP_READY)
     Privs:    SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement

我在上面安装了一个奇怪的小程序：

user@system$ java -jar gp.jar --install applet.cap
CAP loaded
user@system$ 

好了，小程序安装成功了：

user@system$ java -jar gp.jar --list
ISD: A000000003000000 (OP_READY)
     Privs:    SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement

APP: 01020304050601(SELECTABLE)

PKG: 010203040506(LOADED)

user@system$ 

但是当我尝试删除小程序时，我失败了：

user@system$ java -jar gp.jar --delete 01020304050601 --debug --verbose

# Successful Mutual Authentication with Security Level = 01 (CMAC)

A>> 84F28002 0A 4F00<CMAC> 00
A<< E3114F08A0000000030000009F700101C5019E 9000

A>> 84F24002 0A 4F00<CMAC> 00
A<< E3104F07010203040506019F700107C50100 …

我想知道哪些智能卡我能真正运行javacard？afaik它需要"开放平台"操作系统,但是:今天(尤其是德国)手机的USIM卡确实支持这个吗？

我对符合ISO7816-4标准的第一个行业间APDU很感兴趣.这样的APDU可以/允许的最大长度是多少？

我能想到的最长的APDU应该是一个扩展长度的ISO case 4 APDU.这意味着我们有4个字节的标题,3个字节用于扩展Lc,2个字节用于扩展Le.此外,Lc字段允许总共2 ^ 16个字节.考虑到这种最坏情况APDU,2字节大的短值显然不足以解决最后字节的偏移.

有这个问题的最佳做法还是我错过了什么？

我编写了一个Java Card小程序,它将一些数据保存在偏移量的APDU缓冲区中ISO7816.OFFSET_CDATA,并将这些字节作为响应发送.

Util.arrayCopy(Input_Data, (short)0, buffer, (short) ISO7816.OFFSET_CDATA, (short)Datalength);
apdu.setOutgoing();
apdu.setOutgoingLength((short)(DataLength) );

apdu.sendBytesLong(buffer, ISO7816.OFFSET_CDATA, (short)(DataLength));

我在模拟器中测试了这个没有任何问题.但是当我在一张真正的智能卡(由金雅拓制造的Java Card v2.2.1)上进行测试时,我将状态字0x6180作为响应.

我的命令APDU是00 40 00 00 80 Data,其中数据长度为128字节,因此缓冲区中有4 + 128字节,(260-(4 + 128))字节为空.