博士

ロボ子、大変なのじゃ！ eSIMのアーキテクチャに脆弱性が見つかったらしいぞ！

ロボ子

eSIMですか、博士。それは一体どういうことでしょう？

博士

独立系セキュリティ研究者のAdam Gowdiakって人が、GSMAのeSIMアーキテクチャ内のeSIMプロファイル保存チップに脆弱性があるってレポートを公開したのじゃ。

ロボ子

なるほど。具体的にはどのような問題なのでしょうか？

博士

今回の攻撃はKigen（旧ARM）のCardOSベンダー製品に対するものらしいけど、根本的な問題はアーキテクチャにあるみたいじゃ。Oracle Javacardのメモリ安全アーキテクチャが原因らしいぞ。

ロボ子

Javacardですか。以前、博士に教えていただいた、スマートカード向けのJavaプラットフォームですね。

博士

そうじゃ。Javacardは、アプリケーションのコンパイル後に、Javacardでコードを実行する前に「バイトコード検証器」っていうのを使うのじゃ。仕様ではオンカードとオフカードの両方で検証できるんだけど、計算が複雑すぎて、多くのマイクロコントローラではリソースが足りないらしい。

ロボ子

リソース不足で検証が不十分だと、どのような問題が起こるのでしょうか？

博士

Javacardは元々銀行とか決済業界向けに開発されたから、カードを発行する銀行だけがJavaアプレットをカードにロードする鍵を持っていたのじゃ。でも、eSIMだと状況が変わってくる。

ロボ子

eSIMでは、複数の事業者のプロファイルが共有されるのですよね。

博士

その通り！全てのMNO/MVNOが非敵対的で、オフカードのバイトコード検証を実行することを信頼できなくなってしまったのじゃ。Gowdiakさんは2019年にも同じような問題を指摘してたらしいけど、OracleとGemaltoは曖昧な対応しかしてくれなかったみたい。

ロボ子

それは残念ですね。では、解決策はあるのでしょうか？

博士

カード自体が検証できないなら、eUICCからJavacardサポートを削除するか無効化するしかないのじゃ。でも、多くのMNO/MVNOはJavacardサポートを要求するから、GSMAが全てのeUICCで完全なオンカードのバイトコード検証を義務付けるか、eUICCからJavacardサポートを削除するしかないみたい。

ロボ子

なるほど。GSMAの対応が重要になるのですね。

博士

そうじゃな。他にも、GSMAはSAS-UP認定を受けるカードのJVM/JREに関するセキュリティ要件を設けるべきだし、オフカードのバイトコード検証が必要な製品にSAS-UP認定を与えるべきじゃないって言ってるぞ。

ロボ子

セキュリティ要件の強化と、認定プロセスの見直しが必要ですね。

博士

そして、業界全体でJavacardに代わる技術を検討すべきじゃ！

ロボ子

新しい技術への移行も視野に入れる必要があるということですね。今回の脆弱性は、eSIMのセキュリティアーキテクチャ全体を見直す良い機会かもしれません。

博士

ほんとそうじゃな！ ところでロボ子、eSIMって、英語で言うと「イージム」って発音するらしいぞ。easyとSIMを組み合わせたみたいで、なんだか簡単そうに聞こえるのじゃ！

ロボ子

確かにそうですね、博士。でも、今回の件で、eSIMのセキュリティは決してeasyではないことがわかりましたね。