この記事の要点
- セキュアブートは、起動のたびに「次に動かすプログラムが正規のものか」を署名で確かめ、改ざんされていれば起動を止める仕組みです。
- 検証は、書き換えられない場所に置いた信頼の起点(Root of Trust)から始まり、ブートローダ → OS → アプリへと順に確かめていきます。
- ファームウェア更新(OTA 更新)は、見つかった脆弱性を出荷後に直す手段です。更新ファイルにも署名を付け、機器側で検証してから書き込みます。
- 両者はセットで考えます。更新できなければ弱点が残り、更新を検証しなければ更新の経路が攻撃の入口になります。
セキュアブートとファームウェア更新とは、ひと言でいうと何か?
一言でいうと、セキュアブートは「起動時に偽物を動かさない」仕組み、ファームウェア更新は「出荷後に弱点を直す」仕組みです。
IoT機器は長く使われるため、出荷後に脆弱性が見つかるのは避けられません。一方で、更新の仕組みがあると、攻撃者が偽のファームウェアを送り込む入口にもなりえます。そこで、正規のメーカーが署名したものだけを受け入れ、起動時にも改めて確かめる、という二重の守りが必要になります。
IETF の RFC 9019(2021年)は、資源の限られた IoT機器向けのファームウェア更新の構成を示し、更新に認証と完全性の保護が必要だとしています。米国 NIST の SP 800-193(2018年5月)は、ファームウェアを守る考え方を「保護・検知・復旧」の3つに整理しています(いずれも2026年9月27日確認)。
| 観点 | セキュアブート | ファームウェア更新(OTA) |
|---|---|---|
| いつ働くか | 電源を入れて起動するたび | 新しい版を配布・適用するとき |
| 目的 | 改ざんされたプログラムを動かさない | 見つかった脆弱性や不具合を直す |
| 主な仕組み | 署名の検証を起動の段階ごとに連ねる | 署名付きの更新ファイルを配り、機器が検証して書き込む |
| 失敗したとき | 起動を止める、または正常な版に戻す | 書き込みを中止し、元の版で動き続ける |
| 欠けると | 書き換えられた機器が気づかれずに動く | 弱点が残り続ける |
← 表は横にスクロールできます →
起動時の署名検証はどんな流れで進むのか?(信頼の起点)
セキュアブートは、信頼を一段ずつ受け渡していく仕組みです。代表的な流れは次のとおりです。
- 電源を入れると、書き換えできない ROM などに置かれた最初のコード(信頼の起点)が動く。
- 信頼の起点は、あらかじめ保管したメーカーの公開鍵で、ブートローダの署名を検証する。
- 検証に成功したブートローダが、次に OS(またはファームウェア本体)の署名を検証する。
- 同じように、次に動かすプログラムを順に検証してから実行する。
- どこかで署名が合わなければ、その先を実行せず、起動を止めるか、保存しておいた正常な版で起動する。
要点は、最初の一段だけは検証されずに信頼されることです。だからこそ、その部分と公開鍵は書き換えられない場所に置き、ハードウェアで守ります。最初の一段を書き換えられると、それ以降の検証はすべて意味を失います。
署名の検証には、公開鍵暗号とハッシュ関数を使います。メーカーは秘密鍵で署名し、機器は公開鍵で確かめます。証明書や署名の考え方は電子証明書とPKIとはで解説しています。
OTA更新では、どうやって改ざんを防ぐのか?
OTA(Over The Air)更新は、ネットワーク経由で機器のファームウェアを書き換える方法です。台数が多く、現地に行きにくい IoT機器では欠かせません。安全に行うための主な対策を表にまとめます。
| 脅威 | 対策 | ねらい |
|---|---|---|
| 偽の更新ファイルを送り込まれる | メーカーの署名を付け、機器で検証する | 正規の発行元であることを確かめる |
| 配布の途中で書き換えられる | 署名とハッシュ値で完全性を確かめる | 中身が変わっていないことを確かめる |
| 古い弱い版に戻される | 版の番号を確かめ、古い版への書き戻しを拒む | 修正済みの弱点を復活させない |
| 書き込み中に電源が切れる | 新旧の2つの領域を持ち、失敗時は元の版で起動する | 機器が起動できなくなるのを防ぐ |
| 中身を解析される | 必要に応じて更新ファイルを暗号化する | 機密性を守る(改ざん防止とは別の目的) |
← 表は横にスクロールできます →
表の最後の行が取り違えやすい点です。暗号化は中身を読ませない対策で、書き換えを見つける対策ではありません。改ざんの検出には署名とハッシュを使います。
機器に含まれるソフトウェア部品の一覧を管理しておくと、どの機器に更新が必要かを判断しやすくなります。この考え方は SBOM の記事で扱っています。
IoT中級ではどの範囲で、どう問われそうか?
MCPC の公式ページでは、IoTシステム技術検定 中級(80問・90分・4者択一・CBT)の出題カテゴリ「IoT情報セキュリティ対策技術」の比率が20〜25%と図で示され、内訳に「対策技術」が挙がっています(2026年9月27日確認)。当サイトでは、公式テキスト『IoT技術テキスト 第4版』の第7章「IoT情報セキュリティ」がこの範囲に当たると推定しています(章名からの当サイトの判断です)。
出題頻度は公表されていないため、次は考えられる観点の例です。
- 目的の区別:セキュアブートは改ざんの検出、暗号化は秘匿、と役割を取り違えていないか。
- 鍵の使い分け:署名はメーカーの秘密鍵、検証は機器の公開鍵。
- 信頼の起点:検証が書き換えられない場所から始まる理由。
- 更新の安全策:署名の検証、古い版への書き戻しの防止、失敗時の復旧。
試験の形式・日程はIoTシステム技術検定 中級とはにまとめています。
どこで取り違えやすいのか?
選択肢が左の列のように書かれていたら、右の問いで確かめてください。
| 取り違え | 正しい考え方 | 確認する問い |
|---|---|---|
| セキュアブートはファームウェアを暗号化する | 署名を検証して改ざんを見つける仕組み | 中身を隠すのか、正しさを確かめるのか |
| 機器が秘密鍵で署名を検証する | 機器は公開鍵で検証する。秘密鍵はメーカーが保管 | 機器に秘密鍵を置いたら何が起きるか |
| 起動後に一度だけ検査すればよい | 起動の各段階で、次を動かす前に検証する | どの時点で偽物を止めるのか |
| 更新できる機器は安全 | 更新の経路も検証しないと攻撃の入口になる | 更新ファイルの発行元を確かめているか |
| 最新版なら古い版に戻してもよい | 古い版への書き戻しを拒むのが一般的 | 戻した版に既知の弱点はないか |
← 表は横にスクロールできます →
IoTを狙う攻撃全体の流れはIoTの脅威と脆弱性で確認できます。
確認問題1:セキュアブートの目的を説明できるか?
セキュアブートの説明として、最も適切なものはどれか。
- 起動時に署名を検証し、改ざんされたプログラムを動かさない
- 起動時にファームウェアを暗号化し、中身を読まれないようにする
- 起動時に通信を監視し、外部からの不正な接続を遮断して守る
- 起動時に処理を省き、電源を入れてから動くまでの時間を縮める
正解:1。セキュアブートは、次に動かすプログラムの署名を順に検証し、正規のものだけを起動する仕組みです。
2は暗号化による秘匿の説明で、改ざんを見つける仕組みとは目的が異なります。3はファイアウォールなどの通信の制御の説明です。4は高速起動の説明で、安全性とは関係がありません。
確認問題2:署名と検証の鍵を区別できるか?
次の記述ア・イの正誤の組合せとして、正しいものはどれか。
ア:ファームウェアの署名は、メーカーが保管する秘密鍵で作成する。
イ:機器は、自分の中に保存した秘密鍵を使って署名を検証する。
- ア:正 イ:正
- ア:正 イ:誤
- ア:誤 イ:正
- ア:誤 イ:誤
正解:2。アは正しい内容です。イは誤りで、機器が検証に使うのはメーカーの公開鍵です。多数の機器に秘密鍵を配ると、一台から漏れただけで偽の署名を作られてしまいます。
1と3はイを正しいとしている点、4はアまで誤りとしている点で当てはまりません。
確認問題3:OTA更新の安全策を選べるか?
OTA 更新で、改ざんされた更新ファイルの適用を防ぐ対策として最も適切なものはどれか。
- 更新ファイルを暗号化してから、機器へ送るようにしておく
- 更新ファイルの署名を、機器が書き込む前に検証しておく
- 更新を配る時刻を、利用の少ない夜間に限るようにしておく
- 更新ファイルの容量を、差分だけにして小さくしておく
正解:2。署名を検証すれば、正規の発行元から届き、途中で書き換えられていないことを確かめられます。
1は中身を読ませないための対策で、書き換えの検出にはなりません。3は利用者への影響を減らす運用上の工夫です。4は通信量を減らす工夫で、改ざんを防ぐ効果はありません。
同じ分野の問題を本番と同じ4択で試したい場合は、登録不要のIoT中級の無料お試し20問で、全問の解説まで確認できます。
よくある質問
パソコンのUEFIのセキュアブートと同じものですか?
起動時に署名を検証して正規のものだけを動かす、という考え方は同じです。IoT機器では、マイコンの内蔵 ROM などを信頼の起点にするなど、実装の形が機器ごとに異なります。
更新ファイルの暗号化は不要なのですか?
不要ではありません。中身の解析を防ぎたい場合には有効です。ただし、暗号化だけでは改ざんを見つけられないため、署名の検証と組み合わせて使います。
試験対策では規格の番号まで覚える必要がありますか?
出題の詳細は非公開なので断定できません。当サイトでは、規格名より、信頼の起点・鍵の使い分け・更新の安全策を説明できることを優先して学ぶことをすすめています。
出典・参考
本番と同じペースで腕試し
記事の次は、本番形式の問題で。
公式の出題カテゴリの比率どおりに組んだ無料お試しを、登録不要・カード不要で解けます。続きの模試と章別ドリルは買い切りで、月額はかかりません。
あわせて読みたい
当サイトは、モバイルコンピューティング推進コンソーシアム(MCPC)とは関係のない個人が運営する非公式の学習教材です。掲載している問題はすべて当サイトのオリジナルで、実際の試験問題・過去問題・再現問題ではありません。試験の日程・受検料・出題範囲は公式サイト(https://www.mcpc-jp.org/license/ )で必ず確認してください。合格を保証するものではありません。合格の目安は当サイトの推定です。技術・制度の記述は「最終確認日」時点のものです。