一、JavaCard平台概述
各位同学好，我是老张。做JavaCard安全这块有些年头了。今天咱们聊聊JavaCard平台的基础。
很多人一听到JavaCard，第一反应是：“Java还能跑在卡片上？” 没错，确实能。而且它跟咱们平时写的Java程序，差别还挺大。
1.1 JavaCard是什么？
JavaCard，说白了，就是让智能卡能跑Java程序的一套技术规范。你想想看，一张银行卡大小的芯片，里面能跑虚拟机，能执行字节码，还能做加密运算——这就是JavaCard。
我最早接触JavaCard是在做金融IC卡项目的时候。那时候客户要求卡片支持多种应用，传统的C语言开发太痛苦了。后来换成JavaCard，开发效率确实提升不少。
核心定义：JavaCard是Sun公司（现Oracle）推出的一套技术规范，它允许在智能卡等资源受限设备上运行Java程序。它定义了最小的Java虚拟机子集，以及一套标准的API接口。
1.2 JavaCard架构
JavaCard的架构，我习惯把它分成三层来看：
- 硬件层：就是芯片本身，通常包含CPU、RAM、ROM、EEPROM/Flash。资源非常有限，RAM一般只有几KB。
- 系统层：包括JavaCard虚拟机（JCVM）、JavaCard运行时环境（JCRE）、以及底层操作系统。
- 应用层：就是我们开发的Applet，运行在JCRE之上。
这里我画了一张架构图，方便大家理解：
嗯，这里要注意一点：JCVM跟咱们桌面端的JVM差别很大。它只支持部分字节码指令，而且没有垃圾回收的完整实现。为什么？因为资源太紧张了。
1.3 JavaCard与传统Java的区别
我整理了一个表格，把关键区别列出来：
| 对比项 | 传统Java | JavaCard |
|---|---|---|
| 虚拟机 | 完整JVM | JCVM（子集） |
| 内存 | 通常GB级别 | RAM几KB，ROM/EEPROM几十KB |
| 数据类型 | int, long, float, double等 | byte, short, int（可选），不支持float/double |
| 字符串 | java.lang.String | 不支持String类，用byte数组替代 |
| 垃圾回收 | 完整GC | 有限支持或手动管理 |
| 多线程 | 原生支持 | 不支持（单线程模型） |
| 应用模型 | main()入口 | Applet生命周期（install, select, process） |
| 安全性 | 沙箱+安全管理器 | Applet隔离+防火墙机制 |
看到这个表格，你可能会问：“为什么JavaCard不支持float？” 原因很简单——芯片上没有浮点运算单元，软件模拟太慢了，而且也没这个需求。金融交易算的是整数分，谁在乎小数点后几位？
个人经验：我刚开始写JavaCard程序时，习惯性地用了String类型，结果编译报错。后来才意识到，在卡片上所有字符串都得用byte数组处理。这个坑，很多新手都会踩。
1.4 JavaCard应用场景
JavaCard的应用场景，其实比你想的要广得多：
- 金融领域：银行卡、信用卡、电子钱包。这是最传统的应用。我记得2010年左右，国内大部分银行的IC卡都开始用JavaCard了。
- 通信领域：SIM卡、USIM卡。你的手机卡里可能就跑着JavaCard程序。
- 身份认证：电子护照、身份证、门禁卡。这些对安全性要求极高。
- 物联网：嵌入式安全模块（eSE）、TEE安全元件。现在智能家居、车联网都在用。
关键点：JavaCard最大的优势是“多应用”和“后发下载”。一张卡可以同时跑多个Applet，而且发卡后还能通过OTA（空中下载）安装新应用。这在传统C语言开发的卡片上是做不到的。
我曾经参与过一个项目，需要在同一张SIM卡上同时运行银行应用和公交卡应用。如果用传统方案，得把两个应用写在一起，耦合度太高。用JavaCard就简单了——各自开发Applet，通过防火墙机制隔离，互不干扰。
注意：虽然JavaCard提供了安全隔离，但并不意味着绝对安全。我在后面的章节会详细讲，Applet之间的防火墙机制其实存在一些绕过方法。嗯，这里先卖个关子。
好了，这一章的内容就到这里。JavaCard的基本概念、架构、与传统Java的区别、以及应用场景，我都讲清楚了。下一章咱们开始聊攻击面分析——这才是真正的重头戏。
公众号:蓝海资料掘金营，微信deep3321