はじめに

IoT向けセキュアエレメントのパフォーマンス比較記事があったので、翻訳しつつ考察を行う。
記事「Performance Analysis of Secure Elements for IoT」（注１

概要

IoTデバイスは外部との通信機能で大きく機能、用途が広がっている。特にIPV6対応の新しいIoTプロトコルなども登場しており、通信機能の進化は加速している。
特に、IPV6は従来型のゲートウェイを介した通信ではなく、単純なセンサーレベルのIoTデバイスにも一意のアドレスが配布でき、アクセスできるようになっている。
一方、制限されたIoTデバイスの計算資源の中で取り扱うデータは通常のコンピューターと同様のセキュリティレベルを求められるようになっている。
そのようなIoTデバイスのセキュリティの課題に対して、各半導体ベンダーはセキュアエレメントを提供し、セキュリティレベルの確保については支援する機能を提供している。
一方、IoTデバイスのもう一つの制約である消費電力、および処理を行うための実行時間、これがすなわちデバイスのライフサイクルに大きく影響する部分でもある。

セキュアなCoAP通信プロトコルと、DTLSプロトコルを例に５つのセキュアエレメントのパフォーマンスを比較し製品選択のために必要な情報として分析する。

セキュアエレメントについて

セキュアエレメントは、暗号アルゴリズム（主に）をハードウェアで実行するための集積回路（IC）である。暗号アルゴリズムは、AES（Advanced Encryption Standard）、ECC（楕円曲線暗号）、ECDSA（楕円曲線デジタル署名アルゴリズム）、SHA（セキュアハッシュアルゴリズム）、MAC（メッセージ認証コード）など、セキュアエレメントの機能セットに応じてさまざまなものがある。これらの計算負荷の高いアルゴリズムを高速かつ最小限のエネルギーで実行できるように設計されている。さらに、MCUとシリアルインタフェースで接続し、暗号コプロセッサとして機能させる必要がある。
一方、セキュリティペリフェラルを内蔵したMCUでは、このようなアルゴリズムをハードウェアで実装するものも増えている。比較的低速な外部インタフェースではなく、内部データバスに接続されているため、セキュアエレメントと比較して実行時間や消費電力の面で優位性がある。このようなMCUでは、機密性の高い鍵素材をマスターキーで暗号化してからフラッシュメモリに格納するのが一般的である。しかし、機密データを暗号化しても、このようなMCUでは通常、改ざん検知がほとんどできないだけでなく、改ざん防止メモリも提供されない。
逆に、ほとんどのセキュアエレメントは、耐タンパー性メモリ、アクティブシールド回路などの複数のタンパー検出メカニズム、電圧・温度監視、ユーザー定義のタンパーセンサ用入力を備えている。これらの機能は、セキュリティペリフェラルを内蔵したMCUを使用するよりも明らかに大きなメリットとなる。また、サイドチャネル攻撃への高度な対策が施されており、コモンクライテリア認証を取得している製品もある。

本記事では以下のセキュアエレメントを評価している。

- Infineon OPTIGA™️ Trust M
- Infineon OPTIGA™️ Trust X
- Maxim MAXQ1061
- Microchip ATECC608B
- NXP SE050

テストケース

実行時間と消費電力の観点から性能評価を行うため、2つのテストケースを定義した。
1つ目のテストケースは暗号化プリミティブに焦点を当て、2つ目のテストケースは実用的なアプリケーションに焦点を当てる。
具体的には、ノードとサーバーがDTLSハンドシェイクを実行することでセキュアセッションを確立する。
MCU外部のハードウェアアクセラレーションを使用しないベースラインリファレンスを確立するため、MbedTLSを使用してMCU上で暗号機能をソフトウェアで実行した状態で、両方のテストケースを測定した。一方、その後の測定では、評価済みのセキュアエレメントを使用する。その結果、リファレンスとの直接比較やデバイス間の比較を可能とした。

暗号プリミティブ

このテストケースでは、以下の暗号プリミティブについて、個々のセキュアエレメントの性能を評価する。

- 乱数（32 バイト）の生成
- ECC キーペア(secp256r1)を生成する。
- 乱数のSHA-256ハッシュを計算する。
- そのハッシュをECDSAで署名する(先ほどの鍵ペアを使用)
- 署名の検証（先ほどの鍵ペアとハッシュを使用）

DTLSハンドシェイク

このテストケースでは、サーバーとの DTLS ハンドシェイクにより、外部暗号アクセラレーターとしてのセキュアエレメントが実行時間と消費電力に与える影響を実証している。DTLS ハンドシェイクの暗号スイートとして TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 を選択したのは、このスイートが評価対象のすべてのセキュアエレメントで利用可能であるためである。したがって、この選択は、セキュリティの観点から、より良い暗号スイートが間違いなく存在するにもかかわらず、公正な比較を容易にする。最後に、サーバーからダミーデータを取得するためのアプリケーションプロトコルとして CoAP を使用した。
ネットワークの複雑さをできるだけ抑えるため、Threadネットワークはボーダールーターとセキュアノードのみで構成した。さらに、CoAPサーバはボーダールータ上で直接実行され、ハンドシェイクに何らかの形で影響を与える可能性のある未知のものを可能な限り排除する。図3は、このテスト設定を示す。

図4は、64 MHz Arm Cortex-M4 with FPU のスペックを持つ、Nordic社のnRF52840開発キット（DK）と、評価済みのすべてのセキュアエレメントが搭載されたArduinoシールドのフォームファクターを持つ自作PCBであるセキュアエレメントシールドで構成されているセキュアノードの様子を示す。
さらに、Raspberry Pi 3 Model B+とnRF52840ドングル（IEEE 802.15.4の無線コプロセッサとして使用）は、必要なボーダールーターとCoAPサーバーとして機能させる。

測定条件―通信とスリープモード

すべてのセキュアエレメントがサポートする最速の通信であるため、計測を均一にするために、I2Cのクロック速度を400kHzとした。評価対象のセキュアエレメントは、MCUがI2Cを介してビジー状態をポーリングすることを必要とする。また、セキュアエレメントが暗号プリミティブを実行している間、MCUはスリープモードにならない。

測定条件―ファームウェア

Zephyrは、リソースに制約のあるデバイス（主にマイコン）向けに、接続性を重視したオープンソースのリアルタイムオペレーティングシステムである。様々なプロトコルスタックを統合し、幅広いアーキテクチャとプロセッサファミリーをサポートしているため、様々なMCUに対して同じコードをコンパイルすることが可能である。このようにハードウェアや通信インタフェースを抽象化しているため、このRTOSはIoTプロジェクトに最適な選択肢となっている。ZephyrプロジェクトはLinux Foundationの一部であり、これはその構造にも表れている。特に、従来のLinuxと明確な類似性を持つデバイスドライバモデルを備えている。このモデルでは、セキュアな要素ごとにいわゆる外部モジュールを作ることができ、チップベンダーが提供するSDKの優れたカプセル化に寄与している。さらに、OpenThreadというオープンソースのThreadプロトコルの実装が含まれており、暗号ソフトウェアライブラリとしてMbedTLSが使用されている。OPTIGA™️ Trust Xは、それ自体で完全なDTLSハンドシェイクを処理することができるが、我々のセットアップでは、DTLSハンドシェイクはMbedTLSによって処理される。このように、すべてのセキュアエレメントは、すべてのセキュリティとパフォーマンスが重要な計算のために外部暗号プロセッサとして使用され、その結果、セキュアエレメント間の比較は同条件とすることができた。
MbedTLS（バージョン2.7.0以降）は、様々な関数の定義をインクルードガードにパックすることで、代替の暗号実装、いわゆるフックを許可する。
MbedTLSの設定にMBEDTLS_ECDSA_VERIFY_ALTオプションを定義すると、対応するヘッダーファイル内の関数宣言だけが残り、ユーザーは安全な要素を利用した新しい関数の定義を提供できるようになる。以下の設定オプションは、評価されたセキュアエレメントを使用して希望の計算をフックするために定義されている。

- MBEDTLS_ENTROPY_HARDWARE_ALT
- MBEDTLS_ECDSA_SIGN_ALT
- MEDBTLS_ECDSA_VERIFY_ALT
- MEDBTLS_ECDH_COMPUTE_SHARED_ALT
- MBEDTLS_ECDH_GEN_PUBLIC_ALT

測定セットアップ

図6は、Keysight N6705Bパワーアナライザを使用して、実行時間と消費電力を測定している様子を示す。nRF52840 MCUに3.3 Vを供給し、接続されたセキュアエレメントに供給する。MCUとセキュアエレメントの供給電流を測定する。さらに、電源電圧とMCUの補助GPIO（MCUの左側がパワーアナライザの電圧測定チャネルに直接接続されている）を測定し、個々の暗号プリミティブとDTLSハンドシェイクが現在実行されているときに信号を送出する。この設定により、実行時間だけでなく、MCU、セキュアエレメント、およびその両方のエネルギー消費量も取得することができる。計測をPythonで複数回行い統計値を採集する。

結果はMbedtlsのみの基準実装に対して時間と消費電力の相対値で表される。

乱数：

説明と考察：
Mbedtlsのみの基準実装は、裏で乱数シードの作成にMCUを利用した時間と電力が計測されている。
NIST SP 800-90A/B/C またはAIS-31に準拠しているセキュアエレメントは全て200％の時間がかかっており、少なくとも300％の消費電力がシステムとして増加している。
1つ例にとると、NIST CAVPに登録されているATECC608Bの乱数実装はCounter-DRBGとなっており、この計算にリソースが必要ということだろう。
https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?product=12578
AIS-31は乱数生成器仕様まで踏み込んだドイツの規格とのことだが、追って調査。

ECC鍵ペア生成

説明と考察：
MAXQ 1061以外は、Mbedtlsのみの基準実装に対して消費電力と時間で効率よく処理ができている。400kの低速なI2Cに乗せてもこれだけの速度で実行ができるということで
秘密鍵が隠せるという点以外に、64 MHz Arm Cortex-M4 with FPUのnRF52840という非力なMCUの助けになっていることがわかる。

ハッシュ作成

説明と考察：
最も効率の悪いOptiga Trust Xで所要時間は92,100％、消費電力は178,431％と大きな差がついた。
他メーカー製でも20,000％オーバーの効率となった。セキュアエレメントにとって厳しいワークロードと言える。

署名と検証

説明と考察：
MAXQ1061以外の製品の実行時間の削減が著しく、どちらも十分なメリットを出せている数字となっている。

DTLSハンドシェイク

説明と考察：
図 14は、ノード（セキュアエレメントと MCU）の DTLS ハンドシェイクの時間とエネルギー消費を、MCU 上で MbedTLS のみを使用した参照実装に対するパーセンテージで示したものである。例えば、ATECC608BはDTLSハンドシェイクを実行する際に、参照実装で消費されるエネルギーの39%を消費する。つまり、MbedTLSのソフトウェアベースの暗号化操作をATECC608Bのハードウェアベースの代替品で代用すると、DTLSハンドシェイクのエネルギー消費量が61%減少する。パーセントは、ノード（セキュアエレメントとMCU）の時間とエネルギー消費の中央値を基準値（MCU単体）で割ることによって算出されている。

結論と今後の課題

今回、制限された計算資源を持つIoTセンサーノードのシナリオとして、デバイス単体でセキュリティを確保するためにセキュアエレメントを実装することで
どのように消費電力と実行時間に影響があるのか、参考となった。
nRF52840のMCUパワーを基準として期待できる暗号通信ハンドシェイクのアクセラレーションが思いのほか効果があり、MCU単体で行うよりアクセラレーションも期待でき、かつ秘密鍵の秘匿もでき　IoTセンサーノードへBOMとしてセキュアエレメントを追加する費用対効果を具体的に検討するための参考となると思う。

今後、乱数生成、ハッシュ、キーペア生成、署名、検証　どれをセキュアエレメントにやらせるか、

* I2C通信が暗号化されているか
* ホストMCU側でやった方が処理速度、セキュリティ観点で有利な処理か

などの観点でそれぞれの製品の仕様と合わせてベストプラクティスを検討していく必要がある。

また、セキュアエレメントのDTLSハンドシェイクの取り扱いについて、２つの実装アプローチが存在していることがわかった。
１つ目は、「補助型セキュアエレメント」といえる、署名の検証、鍵交換などの計算量の多い暗号アルゴリズム処理のみ担当し、ハンドシェイク処理の主体はmbedtlsなどを利用する形の実装である。
これがATECC608B含めたメジャーな実装で、今回の検証内容である。
もう１つは、DTLSハンドシェイク全体をそのままパススルーで受けて処理を行う「独立型セキュアエレメント」というものである。
これは、Optiga™️ Trust X、およびMaximの一部製品で採用されている実装である。
これらを採用する際の注意点、メリットについても調査が必要である。
詳細の統計手法、条件は元記事をご参照いただきたい。

注１：
https://www.mdpi.com/2624-831X/3/1/1
Mario Noseda 1,†, Lea Zimmerli 1,† , Tobias Schläpfer 2,† and Andreas Rüst 1,∗,†
1, Institute of Embedded Systems, Zurich University of Applied Sciences, 8401 Winterthur, Switzerland; mario.noseda@zhaw.ch (M.N.); lea.zimmerli@zhaw.ch (L.Z.)
2, NatWest Group, NatWest Services (Switzerland) Ltd., 8045 Zuerich, Switzerland; tobias.schlaepfer@iost-company.ch
Correspondence: andreas.ruest@zhaw.ch; Tel.: +41-(0)-58-934-77-01 † These authors contributed equally to this work.
CCライセンス表示 4.0 国際（https://creativecommons.org/licenses/by/4.0/deed.ja）、データカタログサイト利用規約（http://www.data.go.jp）