IoT機器を設計するとき、最初に出てくる話題の一つが「CPUをARMにするか、それともRISC-Vにするか」です。
もちろん重要な選択ですが、実際に製品を作ってみると IoTの安全性を決めるのはCPUよりも“鍵の扱い方”だったりします。
デバイスがネットワークにつながる以上、「その機器は本物か」「クローンではないか」「改ざんされていないか」を判断できなければなりません。
この記事では、ARMとRISC-Vの違いをざっくり整理しつつ、IoTで避けて通れない デバイスキー設計の話をまとめます。
ARMとRISC-V、何が違うのか
IoT機器でよく使われるCPUアーキテクチャは、ほぼこの2つです。
- ARM
- RISC-V
それぞれ方向性が少し違います。ARMは成熟したエコシステムと実績、RISC-Vはオープン性と自由度が魅力です。
ARM
ARMは組み込みの世界では定番です。STM32やNXPなど、多くのMCUがARMベースです。
特徴をざっくり言うと、次のようになります。
- ライセンス制のISA
- ツールやSDKが豊富
- 商用製品の実績が圧倒的に多い
IoT設計で重要になるのが TrustZone です。TrustZoneはCPU内部を「セキュア領域」と「通常領域」に分ける仕組みで、
鍵やセキュア処理を隔離できます。最近のIoT設計では、このTrustZoneを使った PSAセキュリティ設計 がよく使われています。
RISC-V
RISC-VはオープンなISAです。最大の特徴は ライセンス料が不要 という点です。
さらに、命令セットを拡張できる・ベンダー依存が少ない、といったメリットがあります。
最近はGoogleやWestern Digitalなども採用を進めており、IoT向けSoCでもRISC-V採用例が増えてきました。
セキュリティ機能（TrustZone vs PMP）
ARMではTrustZoneが標準的ですが、RISC-Vでは PMP（Physical Memory Protection） が基本になります。
PMPはメモリアクセス制御の仕組みで、read / write / execute の権限を領域ごとに設定できます。
近年はRISC-V側でも、TEE構築のための取り組み（例：Keystone）や、Root of Trustのオープン実装（例：OpenTitan）などが進んでいます。
一方で、どこまでが標準で、どこからがベンダー依存かはSoCごとに差が出やすいので、採用時は仕様確認が重要です。
どちらを選ぶべきか
まとめると、だいたいこんな感じです。
| 項目 | ARM | RISC-V |
|---|---|---|
| 成熟度 | 高い | 成長中 |
| コスト | ライセンスあり | 無料 |
| エコシステム | 非常に豊富 | 発展中 |
| 自由度 | 低め | 高い |
量産製品なら ARMが無難。独自設計やコスト重視なら RISC-Vも魅力的。
そんな位置づけです。
IoTで重要なのは「デバイスキー」
CPUの話をしましたが、実際のIoTセキュリティで重要になるのは デバイスキー です。
これは簡単に言うと 機器ごとに持つ秘密鍵 のことです。
IoT機器はネットワークに接続するため、「この機器は正しいデバイスか」を判断できなければなりません。
そのために使われるのが公開鍵暗号（PKI）の仕組みです。
IoT認証の基本構造（PKI）
基本的な仕組みはシンプルです。
デバイスは 秘密鍵 を持ち、サーバは 公開鍵（またはCA証明書）を持ちます。
デバイスが秘密鍵で署名し、サーバが公開鍵で検証します。
IoTで主流の認証方式：mTLS
現在のIoTシステムでは mTLS（相互TLS） が主流です。
AWS IoTなどでもこの方式が一般的です。流れは次の通りです。
- TLS接続を開始
- デバイス証明書を提示
- サーバ側が証明書を検証
- 認証成功後、暗号化通信を継続
デバイスキーはいつ作るのか（プロビジョニング）
ここが実はIoT設計でかなり重要なポイントです。方法は大きく2つあります。
1) デバイス内生成（おすすめ）
デバイスが初回起動時に鍵ペアを生成する方法です。秘密鍵はデバイスの外に出ません。
セキュリティとしては これが一番安全 です。
2) 製造ライン注入（インジェクション）
工場で鍵を書き込む方法です。量産ではよく使われますが、鍵管理のために HSM を置いたり、
製造ラインのアクセス制御や監査ログなど「工場側のセキュリティ」が重要になります。
鍵はどこに保存するのか
秘密鍵は、安全な場所に保存する必要があります。よく使われるのは次のような方法です。
- Secure Element（鍵管理専用チップ）
- TPM（産業機器・PC系でよく採用）
- MCUのOTP / eFuse（一度書き込むと変更できない領域）
- TEE（TrustZone等の隔離領域）
逆に言うと、普通のFlashにそのまま保存するのは危険です。物理解析やサイドチャネルなど、
“ソフトウェアだけでは守りきれない攻撃”が現実にあります。
最近のIoTセキュリティの流れ（Supply Chain Security）
最近はさらに Supply Chain Security が重要になっています。
製造から運用まで、全体で信頼性を担保する流れが強くなってきました。
たとえば、次のような技術キーワードが登場しています。
- DICE：TPMがなくてもデバイスIDを組み立てる考え方
- IEEE 802.1AR：デバイス証明書（DevID）の標準
- FDO：大量デバイスの自動オンボーディングを支える仕組み
- SBOM：ソフトウェア構成の透明化（脆弱性対応と運用の前提）
IoT機器は「作って終わり」ではなく、長期間運用されるものが多いので、
このあたりの視点があるかどうかで、後々の運用コストも大きく変わってきます。
最後に：Root of Trustの話
IoT機器の設計では、どうしても「ARMにするかRISC-Vにするか」という話になりがちです。
もちろんそれも大事です。
ただ実際のところ、IoTの信頼性を決めるのはCPUそのものではありません。
本当に効いてくるのは、信頼の起点（Root of Trust）をどう作るか、という設計です。
たとえば、次の要素がセットで回っているかどうか。
- Secure Boot：改ざんされたファームが動かない仕組み
- Device Identity：デバイス固有の身分証明
- Key Protection：秘密鍵が外に出ない保護
- Provisioning：鍵を安全に発行・登録する流れ
- Supply Chain Security：製造〜運用までの信頼性
これらがしっかり設計されていれば、ARMでもRISC-Vでも、堅牢なIoTシステムは作れます。
逆に言えば、鍵の扱いを間違えると、どんなCPUでも簡単に破られます。
IoTセキュリティは難しく見えるかもしれませんが、
「信頼の出発点をどこに置くか」という視点で考えると整理しやすくなります。
その出発点こそが Root of Trust です。