Java Card 3.1を掘り下げる

※本記事は、Nicolas Ponsiniによる”Java Card 3.1 explored“を翻訳したものです。

人気のJavaプラットフォームが新しいリリースでIoTアプリケーションとクラウドへの対応を強化

著者：Nicolas Ponsini

2020年7月20日

Java Card 3.1は、Java Card仕様とJava Card Development Kitの主要アップデートです。このリリースの主な目標は、スマートカード、組込みチップ、マイクロプロセッサ・ユニット（MPU）やマイクロコントローラ・ユニット（MCU）内のセキュア・エンクレーブ、携帯電話などで使われるリムーバブルSIMチップといったさまざまな異種セキュア・ハードウェアで、セキュリティ・サービスを利用できるようにすることです。

Java Magazineの記事「Java Card 3.1に迫る」では、Java Cardベースのセキュア・エレメントがIoTで果たす広範な役割を反映した拡張機能やサービスについて取り上げました。具体的には、以下のような新しいアプリケーション設計を可能にする新しいI/OモデルとさまざまなAPI（Certificate、Key Derivation、Monotonic Counter、System Time）です。

• デバイスのエッジでのセキュリティを実現するための、セキュア・エレメントとデバイスの周辺機器との間で直接のチャネルの確立
• IoTクラウド・サービスとの通信の保護
• デバイスが本物であることを第三者に対して証明するさまざまなデバイス・アテステーション・メカニズムの実行

本記事では、Java Card 3.1のデプロイメント・モデル、コア機能、暗号拡張機能について深く掘り下げます。これらはいずれも、セキュリティ・サービスの設計、開発、デプロイ、アップグレードの柔軟性を高めるものです。

拡張デプロイメント・モデルとコア機能

Java Card 3.1では、拡張ファイル形式、静的リソースの管理、バイナリ互換性の改善、配列ビューのサポートが導入されています。これらの機能により、アプリケーションのデプロイやアップグレードが進化し、設計のモジュール性やセキュリティの向上も可能になります。

拡張CAPファイル形式とデプロイメント・モデル：Java Cardのデプロイメント・モデルのベース・ユニットとなるのが、Java Card Converted Application（CAP）ファイルです。CAPファイルには、Java Cardのアプリケーションやライブラリで定義されている、すべてのクラスおよびインタフェースが含まれています。CAPファイルは、Trusted Service Manager（TSM）を使ってJava Cardプロダクトにインストールされます。このインストールは製造時、またはプロダクトが現場にデプロイされてから行われます。

3.1リリースより前のCAPファイルには、1つのJavaパッケージ（アプリケーションまたはライブラリ）のみが含まれ、64 KBのサイズ制限がありました。この制限のために、セキュア・サービスを複数のCAPファイルに分割したことが原因で、アプリケーション設計に制約が生じ、リモート管理が複雑になっていたケースもありました。この問題を回避するため、3.1リリースでは最大8 MBの拡張CAPファイルが導入されました。拡張CAPファイルには、以下のようなメリットがあります。

• 拡張CAPファイルには、アプリケーションやライブラリのJavaパッケージを複数含めることができる。これにより、設計上の制約がなくなり、TSMがデプロイするCAPファイルの数が減少する。
• Javaパッケージが、あるアプリケーションに対してプライベートになることができるようになる。プライベートなパッケージは、プラットフォームでさまざまなアプリケーションがアクセスできるパブリックな共有パッケージとは異なる。これにより、さらに優れた設計や細かいアクセス制御が可能になる。

例として、2つのライブラリを使うIoTアプリケーションについて考えます。1つは専用のストレージ階層を扱うもの、もう1つはあるIoTクラウド・サービスにアクセスする専用のプロトコルを扱うものです。この場合、3つのJavaパッケージが存在することになります。これらのパッケージの実装にユーティリティ・パッケージ（ASN.1解析やJSON解析など、汎用的で同じプラットフォームのさまざまなアプリケーションで共有できるパッケージ）が必要な場合、合計5つのJavaパッケージとなる可能性があります。

拡張CAPファイル形式を使わない場合、5つのCAPファイルをデプロイすることになるでしょう。新しい形式では、このファイルを1つに減らすことも、妥当な組み合わせにすることもできます。図1は、2つのCAPファイルを組み合わせたものを示しています。デプロイの複雑さが大幅に低下しています。IoTアプリケーション専用のライブラリ（プロトコルとストレージ）がIoTアプリケーション自体からしかアクセスできなくなったため、アクセス制御も向上しています。
 

図1：CAPファイルの組み合わせ

CAPファイルの静的リソース：Java Card 3.1では、CAPファイルで静的な読取り専用リソースをサポートしています。このリソースへのアクセスは、同じCAPファイルに含まれるコードで、リソースに関連付けられた識別子を使用した場合にのみ可能です。CAPファイルでは、オブジェクト・ヒープ以外にデータを格納する別の実装も提供しています。静的リソースの例として、アプリケーションを初めて起動する際に使用する構成、デフォルトのパラメータやセキュリティ・ポリシー、事前計算済みの値やデータ・パターンなどが挙げられます。

バイナリ互換性の改善：どんなプラットフォームであっても、下位互換性を確保しつつAPIを進化させるのは難しいことです。Java Card 3.1の仮想マシンでは、finalでないクラスのメソッド・セットや仮想マシン・マッピング表（VMMT）の拡張を妨げていた制限が解消されています。図2に示すように、この強化によってAPIのアップグレードが容易になっています。これは、Java Card API自体を使う場合にも、ユーザー・ライブラリを使う場合にも当てはまります。

この強化は、それ自体が完全に下位互換であり、既存パッケージの再コンパイルは必要ありません。この機能を使用するのは、アップグレードされて新しいメソッドが追加されるクラスを含むライブラリのみです。同様に、アプリケーション・コードがアップデートされて、アップグレードされたAPIに含まれる新しいメソッドが使用された場合、アプリケーションでは自動的にそのコード拡張が使用されます。
 

図2：バイナリ互換性改善の例

配列ビュー：場合によっては、配列全体ではなく、配列のサブセットに対してアクセス、処理、共有を行わなければならないアプリケーションもあるでしょう。データのディフェンシブ・コピー（不変なコピー）を別の配列に作成した場合、追加のメモリだけでなく、元の配列とそのサブセットのコピーとの間でデータ同期が必要になります。Java Card 3.1では、配列ビューと呼ばれる別のメカニズムが提供されています。図3をご覧ください。配列ビューには、2つの大きなメリットがあります。
 

図3：親配列の要素のサブセットに対して作成された配列ビューの例

最初のメリットは、設計がシンプルになり、コードのモジュール性が向上することです。アプリケーションでは、親配列の要素のサブセットに対して配列ビューを作成し、別のモジュールや実行中のサービスのコードを呼び出すときにその配列ビューを使います。これにより、APIの設計がかなりシンプルになります。配列ビューは、入出力パラメータとして直接使用できます。データのコピー、オフセットの管理、データ同期プロトコルの実装は必要ありません。

さらに、配列ビューはアプリケーション間でデータを共有する場合のアクセス制御やセキュリティの向上にもつながります。配列ビューは、読取りと書込みのアクセス制御属性が割り当てられた一時的な配列オブジェクトです。この制御属性によって、セキュリティが強制される設計になっています。これは、証明書オブジェクトのフィールドにアクセスする場合など、変更してはいけない内部メモリのビューを返すAPIなどに便利です。さらに、図4に示すように、2つのアプリケーション（2つのファイアウォール・コンテキスト）間でデータを共有する配列ビューを作成した場合、配列ビューが共有される側のアプリケーションでは、どのアプリケーション・コンテキストを共有するのかを細かく指定できます。
 

図4：配列ビューによるデータ共有の例

新しい暗号拡張機能

セキュリティ製品は、必ずしも暗号製品とは限りません。しかし、セキュリティ製品は機密データの保護や処理に関係することが多く、通常は暗号マテリアルの使用や管理を伴うものと理解されています。そのためJava Cardでは、幅広い暗号プリミティブや暗号アルゴリズムが提供されています。バージョン3.1では、鍵を信頼済みオブジェクトとして扱い、最新アルゴリズムやそれに関連する操作をサポートするための暗号パッケージ更新が行われています。こういったパッケージは、既存のjavacard.securityパッケージおよびjavacardx.cryptoパッケージの追加機能として提供されます。

構成可能な非対称鍵ペア生成のサポート：鍵ペア生成のいくつかのパラメータを構成するために、AlgorithmParameterSpecを実装するアプリケーション向けに新しいメソッドKeyPair.genKeyPair(AlgorithmParameterSpec)が追加されています。たとえば、RSAアルゴリズムの場合は、素数性テストの構成や、乱数生成に使用するシードやアルゴリズムの構成を行うことができます。そのため、アプリケーションにおいて、あらかじめ決められた方法で鍵ペアを生成することもできます。

非対称鍵暗号化は、相互認証に欠かせません。非対称鍵暗号化は通常、鍵ペアと証明書を搭載したクライアントとサーバーで使用されます。IoT市場の性質と規模から、IoTデバイスにこのような暗号マテリアルを搭載するのは時間がかかり、製造時のコスト増加にもつながります。

このような不都合を回避するため、製造時やその後のタイミングでデバイスにシークレットを注入するソリューションもあります。このシークレット（またはそこから導出されるシークレット）は、クラウド・サービスで共有されます。デバイスがデプロイされたら、双方で共有シークレットを共通シードとして使い、あらかじめ決められた方法で鍵ペアを生成することができます。これにより、認証を行うために必要な鍵マテリアルを、デバイスが現場に導入されてからそこに搭載するという、いっそう柔軟な方法が提供されます。

名前付き楕円曲線のサポート：楕円曲線暗号（ECC）による非対称鍵暗号化は、暗号や署名の演算に必要な計算の処理時間や電力消費が少ないため、幅広く使われています。こういった特性のため、ECCはローエンドIoTデバイスに欠かせない要件となっています。

Java Card APIを含め、現在のほとんどの暗号APIで、ECC鍵は曲線とそのドメイン・パラメータに関連付けられています。これは、どんな種類のドメイン・パラメータにも一致する柔軟な方法ではありますが、ドメイン・パラメータを鍵オブジェクトに渡すという管理が追加され、メモリ消費量も増加します。さらに、相互運用性とセキュリティ上の理由から、米国国立標準技術研究所（NIST）などの標準化団体が、一般的なフィールド・サイズのドメイン・パラメータを生成し、公開しています。このようなドメイン・パラメータは名前付き曲線と呼ばれており、名前で直接参照できます。これによって、より効率的なメモリ管理および消費が可能になっています。IoTデバイスでは、プロセッサ能力の多くが暗号化によってすでに消費されているため、この点は特に重要です。

Java Card 3.1では、ECC API（javacard.securityパッケージ）でECC名前付き曲線がサポートされています。アプリケーションでは、対応する鍵パラメータを構成することなく、ECC鍵を作成して使用することができます。次に例を示します。

• 名前付き曲線のECC鍵を生成するためのbuildXECKeyメソッドが、KeyBuilderクラスに追加されています。
• XECKey、XECPublicKey、XECPrivateKeyの各インタフェースを使うことで、関連する鍵の処理が可能です。
• NamedParameterSpecクラスでは、名前付き曲線のリストが提供されます。 
  • オリジナルのECC API（ドメイン・パラメータを明示するもの）にすでに対応するものが存在していた従来の曲線には、Brainpool曲線とSecp曲線があります。これらの曲線は、署名演算を行うためのものです。
  • Edwards 25519、Edwards 448などの新しい名前付き曲線では、鍵共有や署名演算を行います。また、Java Card 3.1では、SM2 Chinese名前付き曲線も使用できます。この曲線は、中国における署名、鍵共有、公開鍵暗号の演算に使用できます。

AESモードの追加（CFBとXTS）：暗号関連のJava Card 3.1 API（javacardx.crypto.Cipherクラス）には、以下のAESモードが追加されています。

• ストリーム暗号化に用いられることが多いCipher Feedback（CFB）モード
• 外部メモリのストレージ保護に使われることが多いXEX tweakable block cipher with ciphertext stealingモード

中国向けアルゴリズム（SM2、SM3、SM4）：Java Card 3.1 APIでは、前述のSM2 Chinese名前付き曲線の他にも、2つの重要な中国向けアルゴリズムをサポートしています。

• 既存のMessageDigestクラスを拡張したSM3ハッシュ・アルゴリズム
• Cipherクラスを拡張したSM4ブロック暗号アルゴリズム

まとめ

本記事と以前の記事では、Java Card 3.1の主な新機能について説明しました。アプリケーションの設計やデプロイ、アップグレードにおける拡張モデル、新しいI/Oインタフェース、暗号拡張機能、いくつかのセキュリティAPI（Certificate、Key Derivation、Monotonic Counter、System Time）などです。

これらの新機能により、IoTデバイスでの新しいセキュリティ・ユースケースが実現し、支払いや認証、携帯通信接続の市場での価値が向上します。IoTでは、セキュア・デバイスから信頼済みの周辺機器にアクセスするだけでなく、Java Cardによって1つのチップで複数のIoTクラウド・プロバイダのさまざまな認証スキームをホストするという、クラウド・セキュリティ関連の使用例もあります。Java Card 3.1では、仮想SIMチップの作成も可能です。そのため、Java Cardによって、SIMアプリケーション（最新のETSI、3GPP、GMSA標準）やオペレータ・サービスが、各種ネットワークのさまざまな通信チップ・アーキテクチャに移行しやすくなります。

機器メーカーやサービス・プロバイダがJava Cardベースのセキュア・エレメントを使えば、種類の異なるセキュア・ハードウェアを組み合わせて、柔軟で将来性がある最新機能を搭載したIoTプロダクトやIoTソリューションを構築することができます。サイバーセキュリティが最大の関心事で、開発者が非標準のセキュリティ・ソリューションを採用したがらない市場では、こういった属性が欠かせません。