33、Java 技术多平台应用与安全发展前景-优快云博客

本文链接：https://blog.youkuaiyun.com/vulkan6gpu/article/details/154427758

Java 技术多平台应用与安全发展前景

1. Java Card 技术概述

Java Card 技术允许用 Java 编程语言编写的程序在智能卡和其他内存受限设备中运行，广泛应用于移动手机、医疗身份卡和金融服务等多个行业领域。它由以下三个部分组成：
- Java 卡虚拟机（JCVM）规范 ：定义了适合智能卡应用的编程语言和虚拟机规范的子集。
- Java 卡运行时环境（JCRE）规范 ：描述了 Java 卡运行时环境的行为，包括内存管理、应用管理、安全执行和其他运行时特性。
- Java 卡应用程序编程接口（API）规范 ：描述了用于编写智能卡应用程序的核心和扩展 Java 卡包及类的集合。

这三个组件为智能卡提供了一个安全的 Java 平台，将应用程序（称为小应用程序）与智能卡供应商的专有技术分离，并为小应用程序提供标准的系统和 API 接口。Java 卡技术具有以下独特优势：
- 互操作性 ：使用 Java 卡技术开发的小应用程序可以在任何基于 Java 卡技术的智能卡上运行，而不受卡供应商和底层硬件的影响。
- 安全性 ：依赖 Java 编程语言固有的安全性来提供安全的执行环境。
- 多应用共存 ：允许多个应用程序在单个智能卡上安全共存，并且可以在发卡后安全地安装新应用程序。
- 与现有标准兼容 ：Java 卡 API 与智能卡的国际标准（如 ISO 7816）兼容。

2. Java Card 虚拟机生命周期

在 Java 卡技术中，虚拟机的执行生命周期就是卡的生命周期。卡上存储的大部分信息是持久的，即使断电也能保留。持久内存技术使智能卡能够在断电时存储信息，当卡下次重置时，虚拟机重新启动并从持久存储中恢复其先前的对象堆。除了其持久性外，Java 卡虚拟机与 Java 虚拟机类似。

小应用程序是为 Java 卡平台编写的程序，其生命周期从通过 javacard.framework.Applet.register 方法成功注册到 Java 卡运行时环境（JCRE）开始。注册的小应用程序会一直存在，直到被删除管理器删除。JCRE 通过小应用程序的公共方法 install 、 select 、 deselect 和 process 与小应用程序进行交互。

小应用程序应实现静态 install(byte[], short, byte) 方法，该方法在小应用程序安装到智能卡时被调用，主要任务是使用构造函数创建 Applet 子类的实例并注册该实例。小应用程序在被显式选择之前处于挂起状态，选择发生在 JCRE 收到 SELECT FILE 应用协议数据单元（APDU）命令，且命令中的名称数据与小应用程序的应用标识符（AID）匹配时，也可以通过 MANAGE CHANNEL OPEN 命令进行选择。选择会使小应用程序成为当前选中的小应用程序。

所有 APDU 都由 JCRE 接收并预处理，在处理过程中，小应用程序可能会抛出 javacard.framework.ISOException 并附带适当的状态字，JCRE 会捕获该异常并将状态字返回给卡接受设备（CAD）或读卡器。当 JCRE 收到 SELECT FILE APDU 命令，且名称匹配某个小应用程序的 AID 时，JCRE 会调用当前选中小应用程序的 deselect 方法，如果该小应用程序在多个逻辑通道上被多次选择，则调用其 Multiselectable.deselect 方法。小应用程序的取消选择也可以由 MANAGE CHANNEL CLOSE 命令请求， deselect 方法允许小应用程序执行任何必要的清理操作，以便其他小应用程序能够执行。

断电时，例如卡从 CAD 中取出或发生机械或电气故障，当重新上电和卡重置时，JCRE 会确保：
1. 瞬态数据重置为默认值。
2. 如果在断电或重置时正在进行的事务被中止。
3. 断电或重置时选中的小应用程序实例隐式取消选择（此时不调用 deselect 方法）。如果 JCRE 实现了默认小应用程序选择，重新上电时，JCRE 还会确保默认小应用程序被选为基本逻辑通道的活动小应用程序实例，并调用默认小应用程序的 select 方法，否则，JCRE 会设置其状态以表明基本逻辑通道上没有活动的小应用程序。

3. Java Card 远程方法调用

Java 卡远程方法调用（JCRMI）是 Java 远程方法调用（RMI）系统的一个子集，它为运行在 CAD 平台上的客户端应用程序提供了一种机制，用于调用卡上远程对象的方法。卡上的传输层由 javacard.framework.service 包中的 RMIService 类提供，它被设计为当基于 JCRMI 的小应用程序是当前选中的小应用程序时请求的服务。JCRMI 消息封装在传递给 RMIService 方法的 APDU 对象中。

事务是对持久数据的一组逻辑更新，例如从一个账户向另一个账户转账就是一个银行事务。事务必须是原子的，即要么所有数据字段都更新，要么都不更新。JCRE 为原子事务提供了强大的支持，如果事务不能正常完成，卡数据将恢复到事务前的原始状态，这种机制可以防止事务中出现断电和程序错误等可能导致数据损坏的事件。

4. Java Card 的小应用程序隔离和对象共享模型

隔离意味着一个小应用程序不能访问另一个上下文中小应用程序的字段或方法，除非另一个小应用程序显式提供访问接口。Java 卡防火墙提供了对最常见安全问题的保护，防止开发者的错误和设计疏忽导致敏感数据泄露给其他小应用程序。要从公共可访问位置获取对象引用，小应用程序必须满足某些访问规则才能使用该引用访问对象。防火墙还能保护对象不被错误代码访问，如果错误代码加载到卡上，防火墙仍然可以保护对象不被该代码访问。

JCRE 维护自己的 JCRE 上下文，该上下文类似于小应用程序的上下文，但具有特殊的系统权限，因此可以执行小应用程序上下文所不允许的操作。在任何时候，VM 中只有一个 JCRE 或小应用程序上下文是活动的。当执行调用类型的字节码时满足某些明确定义的条件时，会发生上下文切换。在上下文切换期间，先前的上下文和对象所有者信息被压入内部 VM 栈，新上下文成为当前活动上下文，被调用的方法在这个新上下文中执行。从该方法退出时，VM 执行恢复上下文切换，将方法调用者的原始上下文从栈中弹出并恢复为当前活动上下文。上下文切换可以嵌套，最大深度取决于可用的 VM 栈空间。

Java 卡对象空间中的任何给定对象都与一个上下文和一个所有者相关联。当创建新对象时，它与当前活动上下文相关联，并由属于该当前活动上下文的小应用程序实例拥有。对象可以由小应用程序实例或 JCRE 拥有。防火墙内的上下文和对象所有权的组合规则如下：
- 每个小应用程序实例都属于一个上下文。
- 来自同一包的所有小应用程序实例都属于同一上下文。
- 每个对象由一个小应用程序实例或 JCRE 拥有。
- 小应用程序实例由其 AID 标识。
- 当执行对象的实例方法或从内部调用的静态类方法时，对象的所有者必须处于活动上下文中。

访问类静态字段时不进行运行时上下文检查，调用静态方法时也不会发生上下文切换。为了使小应用程序能够相互交互以及与 JCRE 交互，提供了一些明确定义且安全的机制，使一个上下文可以访问属于另一个上下文的对象：
- JCRE 入口点对象
- 全局数组
- JCRE 特权
- 可共享接口

5. Java Card 安全 API

Java 卡 API 定义了一个安全 API javacard.security 和一个加密 API javacardx.crypto ，它们分别提供与 J2SE 对应 API java.security 和 javax.crypto 类似的功能。具体来说，这些 API 提供了用于在 Java 卡上实现安全和加密框架的公开可用功能的类和接口。 javacard.security 包中的类提供了执行安全和加密功能的算法定义。

Java 卡安全 API 的加密功能包括对对称和非对称签名算法以及密钥协商算法的支持。加密 API 支持与 J2SE 中类似的密钥加密和密码抽象。

6. Java 2 微型版（J2ME）简介

J2ME 是 J2SE 的一个子集，进一步分为两种配置：连接受限设备配置（CLDC）和连接设备配置（CDC）。在设备配置中，定义了指定可用 Java API 的配置文件。例如，CLDC 定义了针对移动电话的移动信息设备配置文件（MIDP）。由于这些小型设备的计算资源有限，安全模型和支持机制的粒度各不相同。

CLDC 1.0 指定了一个相当粗略的安全模型，类似于旧时的沙箱。MIDP 2.0 定义了一个更高级的安全模型，引入了可信应用程序的概念。在 MIDP 中，应用程序被称为 MIDlet 套件。一旦确定 MIDlet 套件是可信的，就会根据域策略授予的权限允许访问。保护域所有者定义了设备如何对 MIDlet 套件进行身份验证和验证，以便将其绑定到保护域。MIDP 2.0 指定的一种绑定机制是基于 X.509 PKI 的机制，用于确定 MIDlet 是否可信。在这种机制下，类似于 J2SE 代码签名，MIDlet 套件的真实性和完整性得到验证，如果成功，MIDlet 套件将被放入相应的保护域。

J2ME 的配置和配置文件不是静态的，未来将拥有更丰富的安全功能。在 Java 社区中，正在进行定义安全和信任服务 API 的工作。该 API 定义了一个抽象层，用于访问和使用集成到设备中的安全元素。

7. J2ME 的安全发展趋势

J2ME 设备正在发展成为分布式环境中的可信计算元素。密码学的进步使得受资源限制（如电源、带宽、内存大小和计算能力）的设备能够在本地执行密码功能。椭圆曲线密码学（ECC）已经达到了成熟水平，我们可以期待在小型设备中看到其实现和部署。

ECC 提供了与当今更普遍使用的密码系统相当的加密强度，但密钥大小要小得多。这种密钥大小的减少使得在资源受限的环境中实现强加密成为可能。具体来说，我们很快将看到具有 ECC 实现的 J2ME 设备，这可能包括椭圆曲线数字签名算法（ECDSA）。ECDSA 可用于为应用程序提供身份验证和完整性保护机制。更重要的是，支持 ECC 的 TLS 密码套件正在由 IETF 进行标准化。当然，为了使通信对等方之间能够协商和使用 ECC 密码套件，对等方的 TLS 实现也必须支持该密码套件。因此，在标准制定完成后不久，预计 J2SE 也将提供此类支持。

8. J2SE 未来的安全增强

J2SE 可能是有史以来最安全、功能最丰富的开发和部署环境，但仍有进一步提升的空间，以下是一些可能的增强方向：
- 虚拟机增强 ：CLDC 规定的预验证和运行时验证的划分是一个很好的例子，这种方式带来的性能提升和简化值得考虑纳入 J2SE。未来设想 Java 编译器（ javac ）支持生成栈映射，并且修订类文件规范以支持必要的属性，以便以向后兼容的方式携带信息。
- 语言增强 ：J2SE 现有的访问控制算法能防止一些编程错误转化为安全漏洞，但仍有改进空间。例如， doPrivileged 原语虽然必要且有用，但使用匿名类作为 PrivilegedAction 参数的常见习惯增加了代码的可读性复杂度。可以使用更合适的语言结构，如具有保证序言和尾声执行语义的块结构，会更易于理解。此外，闭包可以通过放宽内部类作用域内变量使用的语言要求来简化特权代码的实现。
- 可信计算基增强 ：
- 权限选择性启用 ：某些情况下，应用程序可能只想启用其被授予的部分权限。目前可以通过向 doPrivileged 方法提供 AccessControlContext 对象来实现，但这种机制使用起来很繁琐。未来可以丰富该原语，使其接受一个额外的参数，可能是 Permission 、 PermissionCollection 或 Permissions 类型，用于指定要启用的权限。或者简化减少特权的机制，利用声明式范式和策略管理的进展。
- 系统域细分 ：为了更好地保护系统，系统代码应在多个系统域中运行，每个域保护特定类型的资源并被赋予一组特殊的权利。例如，文件系统代码和网络系统代码在不同的域中运行，前者没有网络资源的访问权限，后者没有文件系统资源的访问权限，这样可以将一个系统域中的错误或安全漏洞的风险和后果限制在其边界内。
- 类加载器改进 ：类加载器在安全方面非常敏感， ClassLoader 类的规范方式可以改进。目前，小程序和应用程序只有在系统安全策略允许的情况下才能创建类加载器，唯一的例外是 URLClassLoader ，这种严格的限制可能会阻碍某些应用程序的开发。
- 非类内容处理 ：当小程序或应用程序运行带有签名内容（类和其他资源）时，代码签名的 JAR 和清单规范允许非常灵活的格式。同一存档中的类可以未签名、用一个密钥签名或用多个密钥签名，存档中的其他资源（如音频剪辑和图形图像）也可以签名或未签名。但目前不清楚如果存档中的任何类被签名，图像和音频剪辑是否需要用相同的密钥签名。如果图像和音频文件用不同的密钥签名，它们能否放在同一个小程序查看器或浏览器页面中，还是应该发送到不同的查看器，这些问题需要在平台和产品之间保持一致的解决方案。

综上所述，Java 技术在不同平台上都有着广泛的应用和不断发展的安全需求。从 Java Card 到 J2ME 再到 J2SE，每个平台都有其独特的安全特性和发展方向。未来，随着技术的不断进步，Java 平台的安全性将不断增强，以适应日益复杂的应用场景和安全挑战。

Java 技术多平台应用与安全发展前景

9. Java 各平台安全特性对比

10. Java 平台安全发展的流程图

下面是一个 mermaid 格式的流程图，展示了 Java 平台安全发展的大致过程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A([Java 技术起步]):::startend --> B(Java Card 技术发展):::process
    B --> C(小应用程序隔离和安全机制建立):::process
    C --> D(J2ME 出现):::process
    D --> E(CLDC 1.0 沙箱安全模型):::process
    E --> F(MIDP 2.0 可信应用程序模型):::process
    F --> G(J2SE 持续发展):::process
    G --> H(安全增强措施提出):::process
    H --> I([未来安全特性不断完善]):::startend

11. Java 平台安全发展的关键时间节点

Java 平台的安全发展经历了多个关键时间节点，这些节点推动了 Java 安全技术的不断进步，以下是一些重要的时间节点：
- Java Card 技术诞生 ：为智能卡和内存受限设备提供了安全的 Java 运行环境，实现了小应用程序的隔离和安全交互。
- J2ME 出现 ：针对计算资源有限的小型设备，开始探索适合这类设备的安全模型。
- MIDP 2.0 发布 ：引入可信应用程序概念，提升了移动设备应用的安全性。
- J2SE 持续改进 ：不断提出安全增强措施，如虚拟机、语言和可信计算基的改进。

12. Java 平台安全发展的挑战与应对

13. Java 平台安全发展的未来展望

未来，Java 平台的安全发展将继续朝着更安全、更高效、更灵活的方向前进。随着物联网、云计算等技术的发展，Java 平台将面临更多的安全挑战，同时也将迎来更多的发展机遇。

在安全技术方面，我们可以期待更多先进的加密算法和安全机制的应用，如量子加密技术的研究和应用，将进一步提升 Java 平台的安全性。在性能优化方面，将不断探索更高效的验证和安全检查机制，减少安全机制对系统性能的影响。在应用场景方面，Java 平台将在更多领域发挥重要作用，如金融科技、医疗健康、工业互联网等，为这些领域的安全发展提供有力支持。

总之，Java 平台的安全发展是一个不断演进的过程，我们需要持续关注安全技术的发展动态，不断完善 Java 平台的安全体系，以适应日益复杂的安全环境和应用需求。

14. Java 平台安全发展的总结

Java 技术在不同平台上的安全发展历程是一个不断创新和完善的过程。从 Java Card 为智能卡提供安全解决方案，到 J2ME 适应小型设备的安全需求，再到 J2SE 作为通用开发环境的持续改进，每个平台都在不断探索和实践，以提升自身的安全性。

通过对 Java 各平台安全特性的分析，我们了解到不同平台根据其应用场景和资源限制，采用了不同的安全模型和机制。未来，随着技术的不断进步，Java 平台将继续加强安全防护，应对各种安全挑战，为用户提供更加安全、可靠的应用环境。无论是开发者还是用户，都应该关注 Java 平台的安全发展，合理利用安全机制，保障应用的安全运行。

同时，Java 平台安全发展的经验也为其他编程语言和平台的安全建设提供了有益的借鉴。在全球数字化的大背景下，安全是技术发展的基石，只有不断提升安全水平，才能推动技术的健康发展，为社会创造更大的价值。