概要

玄関のスマートロックを開ける。
腕時計型のデバイスで心拍数を測る。
交通系ICカードをかざして改札を通る。
部屋の温度センサーが、クラウドにデータを送る。

こうした機器は、私たちの生活の中で自然に使われています。
一つ一つは小さく、普段はあまり「コンピュータ」として意識しないかもしれません。

しかし、これらの機器も裏側では、データを送ったり、保存したり、操作を受け付けたりしています。
もし通信内容を盗み見られたり、操作命令を書き換えられたり、偽物の機器になりすまされたりすると、安全性やプライバシーに関わる問題につながります。

そのため、小さな機器にも暗号技術は必要です。

ただし、小さな機器にはサーバーやPCほどの余裕がありません。
メモリが少ない、電池で長期間動かしたい、処理に時間をかけられない、実装サイズを小さくしたい。
このような制約があるため、通常の暗号技術をそのまま使うことが難しい場合があります。

たとえるなら、大きなキッチンで使う本格的な調理器具を、キャンプ用の小さなコンロと限られた道具だけでそのまま使うのが難しい、という感覚に近いです。

そこで登場するのが、軽量暗号です。

軽量暗号は、「安全性を軽くした暗号」ではありません。
限られた資源の中でも、必要な安全性を実現しやすいように設計された暗号技術です。

本記事では、軽量暗号について、次の流れで整理します。

身近な小さな機器の裏側を見る
小さな機器では、どのような制約が問題になるのかを確認する
軽量暗号の考え方と、混同しやすいポイントを整理する
NIST SP 800-232で標準化されたAsconの位置づけを見る
AESとの違いを確認し、どのように使い分けるかを考える
最後に、軽量暗号だけでは守れない部分を確認する

この記事の目的は、Asconの内部構造や数式をいきなり細かく追うことではありません。
まずは、暗号技術の全体像の中で「軽量暗号がなぜ必要になるのか」をつかむことを目指します。

この記事で分かること

この記事では、次の内容を整理します。

小さな機器にも暗号技術が必要になる理由
IoTや組込み機器で問題になりやすい制約
軽量暗号の基本的な考え方と、「軽量」＝「弱い」ではない理由
AESなど既存暗号との関係
NIST SP 800-232とAsconの概要
軽量暗号を使うときの注意点

対象読者

この記事は、次のような人を想定しています。

情報セキュリティを学び始めた人
IoTや組込み機器のセキュリティに関心がある人
「軽量暗号」という言葉は聞いたことがあるが、何が軽いのか分からない人
AESやハッシュ関数などの名前は知っているが、制約環境での使い分けはまだ曖昧な人
NIST SP 800-232やAsconの位置づけをざっくり把握したい人

本記事で扱わないこと

本記事は軽量暗号の全体像をつかむことを目的にしているため、次の内容は深く扱いません。

Asconの内部構造の詳細
置換層、S-box、拡散層などの数式レベルの説明
ハードウェア実装におけるゲート数の厳密な比較
サイドチャネル攻撃対策の具体的な実装
暗号ライブラリを使ったコード実装
製品への導入手順や認証取得の具体的な流れ

これらは、必要に応じて別記事で深掘りする想定です。

また、本記事に出てくるコードは、軽量暗号や制約環境の考え方を理解するための学習用サンプルです。
実際の製品やサービスでは、暗号処理を独自実装せず、利用環境に合った標準仕様、ライブラリ、ハードウェア機能、ベンダーの公式ドキュメントを確認することを前提にしてください。

コード例を読む場合の前提

本記事では、考え方を確認するためにC風の疑似コードをいくつか使います。
コードを読む場合は、次の前提で見てください。

項目	内容
目的	軽量暗号が必要になる背景や、制約環境での設計判断を理解するための学習用
想定環境	小型マイコンやIoT機器をイメージした説明用の環境
コードの種類	C言語に近い疑似コード。一部は処理の流れを示すために単純化
扱う内容	バッファ、メモリ、nonce、鍵管理、ファームウェア更新などの考え方
注意点	実製品の暗号処理へそのまま流用しない。実装時は標準仕様と検証済みライブラリを確認する

この記事のコード例は、「こう実装すれば安全」という完成形ではありません。
むしろ、どのような点を見落とすと危ないのかを理解するための補助として使います。

全体の流れ

この記事では、次の順番で話を進めます。

1. いつもの小さな機器の裏側で起きていること

ここまでの概要では、スマートロックやセンサーのような小さな機器にも暗号技術が必要になる、と説明しました。

ただ、いきなり「IoT機器には暗号が必要です」と言われても、少し遠い話に感じるかもしれません。
そこでまずは、身近な小さな機器が、実際にどのようなデータを扱っているのかを見ていきます。

1.1 「小さな機器」は、ただ動いているだけではない

スマートロック、スマートウォッチ、温度センサー、ICカード、スマート家電、車載機器。
これらは見た目こそ小さいですが、裏側ではさまざまな処理をしています。

たとえば、スマートロックは「ドアを開けてよいか」を判断します。
スマートウォッチは、心拍数や活動量のような身体に関係するデータを扱います。
温度センサーは、測定した値を無線で送ることがあります。
ICカードは、利用者や残高、通過記録に関係する情報を扱うことがあります。

つまり、小さな機器であっても、次のようなデータに関わっている場合があります。

身近な機器の例	扱うことがあるデータ	守れないと困ること
スマートロック	解錠命令、利用者情報、操作履歴	勝手に開けられる、操作履歴を改ざんされる
見守りセンサー	人の動き、温度、異常検知の通知	生活パターンを知られる、異常通知を妨害される
スマートウォッチ	心拍数、歩数、睡眠、位置情報など	健康情報や行動履歴を知られる
ICカード・RFIDタグ	識別情報、利用記録、認証情報	なりすましや不正利用につながる
医療機器・医療センサー	測定値、設定値、機器の状態	誤った値や命令が安全性に影響する
車載機器	通信データ、制御情報、認証情報	不正な操作や改ざんが安全性に関わる

このように整理すると、暗号技術はサーバーやPCだけの話ではありません。
小さな機器であっても、通信する、保存する、認証する、更新する、といった処理があるなら、そこには情報を守る必要があります。

NISTの軽量暗号に関する説明でも、IoTを構成する機器やRFIDタグ、医療用インプラントのような小型電子機器は、PCやスマートフォンほどの計算資源を持たない一方で、サイバー攻撃からの保護が必要だと説明されています。
参考: NIST Finalizes ‘Lightweight Cryptography’ Standard to Protect Small Devices

1.2 小さな機器でも、守りたい性質は大きく変わらない

小さな機器であっても、守りたい性質は基本的には他のシステムと大きく変わりません。

たとえば、通信内容を他人に読まれたくないなら 機密性 が必要です。
操作命令や測定値が途中で書き換えられていないことを確認したいなら 完全性 が必要です。
通信相手が本物か、正規の機器かを確認したいなら認証が必要です。

これは、暗号技術の全体像で見た「何を守るのか」という考え方と同じです。
違うのは、それを使う場所が、サーバーやPCではなく、より小さく制約の多い機器になるという点です。

たとえば、スマートロックに送る命令が「開ける」なのか「閉める」なのかは、とても重要です。
通信内容が盗み見られることも問題ですが、それ以上に、命令が途中で書き換えられたり、偽物の命令が送られたりすると直接的な被害につながります。

また、医療センサーや見守りセンサーでは、測定値そのものが個人の生活や健康に関係する場合があります。
そのため、単に「データ量が小さいから重要ではない」とは言えません。

小さなデータでも、意味が大きいことがあります。

1.3 ファームウェア更新にも暗号が関わる

小さな機器では、購入後にファームウェアを更新することがあります。
ファームウェアとは、機器の中で動く基本的なソフトウェアのようなものです。

スマートフォンのOSアップデートほど目立たないかもしれませんが、IoT機器や組込み機器でも、不具合修正やセキュリティ更新のためにファームウェア更新が行われることがあります。

ここで重要なのは、機器が「その更新データは本当に正規のものか」を確認できることです。
もし攻撃者が作った偽物の更新データを受け入れてしまうと、機器の動作そのものを乗っ取られる可能性があります。

この確認には、ハッシュ関数やデジタル署名の考え方が関係します。

ハッシュ関数: 更新データが途中で変わっていないかを確認する材料になる
デジタル署名: 正規の作成者が出した更新データかを確認する材料になる

NISTの軽量暗号標準に関するニュースでも、ハッシュはデータの指紋のように働き、ソフトウェア更新時にマルウェアが紛れ込んでいないか確認する用途に触れられています。
参考: NIST Finalizes ‘Lightweight Cryptography’ Standard to Protect Small Devices

💡 豆知識
「小さな機器」と聞くと、購入したときのままずっと同じ動きをするものを想像するかもしれません。
しかし実際には、セキュリティ修正や機能改善のために更新が必要になることがあります。
その更新データが本物かを確認するところにも、暗号技術が関わっています。

1.4 「小さいから攻撃されない」とは言えない

ここで注意したいのは、「小さな機器だから攻撃対象にならない」とは言い切れないことです。

むしろ、小さな機器は数が多く、長期間使われ、利用者が存在を意識しにくい場合があります。
また、玄関、車、医療、工場、家庭内ネットワークのように、現実世界とつながる場面で使われることもあります。

そのため、1台ごとの処理能力は小さくても、セキュリティ上の影響は小さいとは限りません。

もちろん、すべてのIoT機器が同じリスクを持つわけではありません。
温度を測るだけのセンサーと、ドアの開閉や医療機器の動作に関わる装置では、求められる安全性も変わります。

大切なのは、機器の大きさではなく、その機器が何を扱い、何につながっているのか を見ることです。

1.5 この章のまとめ

ここまで見ると、小さな機器にも暗号技術が必要になる理由が少し見えてきます。

小さな機器も、通信します。
データを保存します。
操作命令を受け取ります。
更新データを取り込みます。

その中には、盗み見られたくない情報、書き換えられると困る命令、本物か確認したい相手が含まれます。

一方で、小さな機器にはサーバーやPCほどの余裕がないことがあります。
計算能力、メモリ、電力、実装サイズに制約があるため、一般的な暗号技術をそのまま使うことが難しい場合があります。

NIST IR 8114では、従来のNIST承認暗号標準は汎用コンピュータでよく動くように設計されてきた一方、リソース制約のある小型デバイスでは、現在のアルゴリズムを実装できても性能が受け入れられない場合があると説明されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

この問題意識から出てくるのが、軽量暗号です。

つまり、軽量暗号は次のような問いへの答えとして考えると分かりやすいです。

小さな機器でも、通信やデータを安全に守りたい。
でも、メモリや電力にはあまり余裕がない。
では、そのような環境で暗号技術をどう使えばよいのか。

次の章では、この「余裕がない」という部分をもう少し具体的に見ていきます。
軽量暗号を理解するには、まず小さな機器がどのような制約を持っているのかを知ることが大切です。

2. ただし、小さな機器には余裕がない

前の章では、スマートロック、センサー、ICカード、医療機器のような小さな機器にも、通信・保存・認証・更新といった処理があり、暗号技術が必要になることを見ました。

ここで次に考えたいのが、「暗号を使いたいとして、その機器に暗号を動かす余裕があるのか」 という問題です。

サーバーやPCであれば、CPU、メモリ、電源、ストレージにある程度の余裕があります。
しかし、IoT機器や組込み機器では、数年間バッテリーで動く、非常に小さなマイコンで動く、通信量をできるだけ減らす、製造コストを抑える、といった制約が出てきます。

暗号技術を「安全のために入れればよい」と考えるだけでは不十分です。
小さな機器では、安全性を保ちながら、どれだけ少ない資源で動かせるか も大切になります。

NIST IR 8114では、デスクトップやサーバー向けに最適化された従来の暗号標準は、制約のある小型デバイスでは実装が難しい場合や、実装できても性能が受け入れられない場合があると説明されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

2.1 何が「余裕がない」のか

小さな機器の制約は、一言で「性能が低い」とまとめられがちです。
しかし、実際にはいくつかの観点に分けて考える必要があります。

観点	サーバー・PCでの感覚	IoT・組込み機器で問題になりやすいこと
CPU性能	比較的高い処理能力がある	暗号処理に時間がかかる場合がある
RAM	一時的な作業領域に余裕がある	バッファや中間値を置く余裕が少ない場合がある
ROM / Flash	プログラムサイズに余裕があることが多い	暗号ライブラリのコードサイズが問題になる場合がある
電力	電源供給が安定しやすい	バッテリー駆動、環境発電、無電源RFIDでは消費電力が重要になる
レイテンシ	多少の処理時間を許容できる場面が多い	車載・制御系では応答の遅れが問題になる場合がある
ハードウェア面積	回路規模を増やしやすい	ICカードやRFIDではゲート数・面積・コストが問題になる
更新のしやすさ	OSやライブラリを更新しやすい	一度設置すると長期間更新されにくい場合がある

ここで意識したいのは、どの制約が厳しいかは機器によって違うことです。

たとえば、電源につながったスマート家電では、電力よりもファームウェア更新や通信の安全性が問題になりやすいかもしれません。
一方で、電池で数年間動くセンサーでは、1回の暗号処理に使う電力や通信量が大きな問題になります。

RFIDタグのように、リーダーから受け取る電磁波で動くような機器では、そもそも使える電力や回路面積が非常に限られます。
NIST IR 8114でも、バッテリーを持たないRFIDタグでは周囲から得られる電力が限られるため、暗号アルゴリズムは小さいゲート数だけでなく、厳しいタイミングや電力要件も満たす必要があると説明されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

2.2 RAMが少ないと、バッファを置くだけでも問題になる

暗号処理では、鍵、nonce、平文、暗号文、認証タグ、中間状態などを扱います。
PC上ではあまり意識しないかもしれませんが、小さなマイコンでは、これらを置くためのRAMも貴重です。

NIST IR 8114では、一部のマイクロコントローラではRAMが64バイト以下、さらに少ないものでは16バイト程度まで小さい例があると説明されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

ここで、説明用にかなり単純化したC風の例を見てみます。

注意: 以下は、暗号アルゴリズムを実装するコードではありません。
「小さな機器では、バッファを確保するだけでもRAMを使う」という感覚をつかむための説明用コードです。
実際の暗号処理では、自作実装ではなく、標準仕様に沿った検証済みライブラリを使うべきです。

#include <stdint.h>

#define RAM_LIMIT_BYTES 64
#define PAYLOAD_SIZE 128
#define TAG_SIZE 16

void bad_example(void) {
    // センサー値など、送信したいデータをまとめて置くバッファ
    uint8_t plaintext[PAYLOAD_SIZE];

    // 暗号化後のデータを置くバッファ
    uint8_t ciphertext[PAYLOAD_SIZE];

    // 改ざん検知に使う認証タグを置くバッファ
    uint8_t tag[TAG_SIZE];

    // この時点で 128 + 128 + 16 = 272 バイトを使う
    // RAMが64バイト程度の機器では、この考え方自体が成り立たない
}

このコードは、PCで見ると何も問題なさそうに見えます。
しかし、RAMが64バイト程度しかない機器を考えると、128バイトの配列を2つ置くだけで完全に予算オーバーです。

もちろん、実際の機器ではスタック、グローバル変数、通信処理、センサー制御、OSやランタイムが使う領域もあります。
暗号処理だけがRAMを独占できるわけではありません。

そのため、制約環境では「データを全部メモリに載せてから処理する」のではなく、できるだけ小さな単位で処理する設計が重要になります。

たとえば、概念的には次のように、小さなチャンクごとに処理する考え方があります。

#include <stdint.h>
#include <stddef.h>

#define CHUNK_SIZE 16

void process_streaming_example(const uint8_t *input, size_t input_len) {
    uint8_t chunk[CHUNK_SIZE];

    for (size_t offset = 0; offset < input_len; offset += CHUNK_SIZE) {
        // 残りの長さを確認し、最後のチャンクだけ短くなる場合に備える
        size_t remaining = input_len - offset;
        size_t current_size = remaining < CHUNK_SIZE ? remaining : CHUNK_SIZE;

        // 本来はここで input[offset] から current_size バイトを読み込む
        // ここでは説明用なので、実際のコピー処理は省略する

        // 小さな単位で暗号処理やハッシュ処理に渡すイメージ
        // 実際には、利用する暗号ライブラリのAPIに従って処理する
        // encrypt_or_hash_update(chunk, current_size);
    }
}

この例で伝えたいのは、暗号の中身そのものではありません。
小さな機器では、アルゴリズムの安全性だけでなく、処理の進め方やメモリの使い方も重要になる という点です。

💡 豆知識
組込み開発では、PC上では気にしないような数十バイトの差が重要になることがあります。
「たった128バイトの配列」でも、RAMが64バイトしかない機器では置けません。
暗号方式を選ぶときも、このような現実的な制約を意識する必要があります。

2.3 ROMやコードサイズも無視できない

RAMは実行中の作業領域ですが、ROMやFlashはプログラム本体を保存する領域です。

暗号ライブラリを使う場合、暗号アルゴリズム本体だけでなく、利用モード、乱数生成、鍵管理、エラー処理、テストコード、場合によっては複数方式への対応などが関係します。
これらをすべて入れると、ファームウェア全体のサイズが大きくなることがあります。

小さな組込み機器では、ファームウェア領域に余裕がないこともあります。
そのため、暗号方式を選ぶときには、処理速度だけではなく、コードサイズ も重要な判断材料になります。

NIST IR 8114では、ソフトウェア実装における資源要件として、レジスタ数、RAM使用量、ROM使用量が挙げられています。ROMにはプログラムコードや固定データが置かれ、RAMには計算途中の値が置かれるため、テーブル参照で高速化するか、その場で計算してメモリを節約するか、といったトレードオフが生じます。
参考: NIST IR 8114: Report on Lightweight Cryptography

たとえば、説明用にかなり単純化すると、次のような考え方です。

// 例1: テーブルを使うと計算は速くなる場合があるが、ROMを消費する
static const uint8_t lookup_table[256] = {
    // 実際の値は省略
};

uint8_t use_table(uint8_t x) {
    // テーブル参照で値を得る
    // 速度面では有利な場合があるが、テーブル分のROMが必要になる
    return lookup_table[x];
}

uint8_t calculate_on_the_fly(uint8_t x) {
    // テーブルを持たず、その場で計算するイメージ
    // ROMは節約できる場合があるが、計算時間や消費電力が増える可能性がある
    return (uint8_t)((x << 1) ^ (x >> 1));
}

このコードも、暗号処理そのものを示しているわけではありません。
ただし、軽量暗号を理解するうえでは、速くするためにテーブルを持つとROMを使い、ROMを節約すると計算時間が増える場合がある という感覚が大切です。

2.4 電力と電池寿命もセキュリティ設計に関係する

IoT機器やセンサーでは、電力も重要です。

たとえば、山間部や工場内に設置されたセンサーが、電池で数か月から数年動くことを期待される場合があります。
このような機器では、1回の通信や暗号処理に使うエネルギーが積み重なると、電池寿命に影響します。

また、RFIDタグのように、リーダーから受け取る電磁波で動く機器では、使える電力が非常に限られます。
NIST IR 8114でも、周囲から電力を得る機器では消費電力が重要であり、電池駆動の機器では一定期間に消費するエネルギーが特に重要だと説明されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

ここで面白いのは、セキュリティ対策を入れること自体が、機器の寿命や使い勝手に影響する場合があることです。

もちろん、安全性を犠牲にしてよいわけではありません。
しかし、暗号処理が重すぎて電池がすぐ切れる、通信が遅くなる、応答が間に合わない、という状態では、実際の製品として使いにくくなってしまいます。

そのため、軽量暗号では次のようなバランスを考えます。

2.5 レイテンシが問題になる場面もある

暗号処理は、通信の前後に入ることが多いため、処理が遅いと応答時間に影響します。

Webページを開くときに少し遅い程度なら、利用者が待てる場合もあります。
しかし、車載機器、工場の制御機器、医療機器のように、タイミングが重要な場面では、遅延が大きな問題になる可能性があります。

NIST IR 8114では、レイテンシは要求から出力までの時間として説明され、ステアリング、エアバッグ、ブレーキのような車載用途では非常に速い応答が必要になる例が挙げられています。
参考: NIST IR 8114: Report on Lightweight Cryptography

このため、軽量暗号では「最高速度」だけではなく、必要なタイミングに間に合うか も重要になります。

たとえば、1秒に大量のデータを処理できるかというスループットよりも、1回の短い制御メッセージをすばやく処理できるかの方が重要な場面もあります。

2.6 ハードウェアでは回路面積やゲート数も見る

ソフトウェアで動かす場合は、RAMやROM、CPU時間が主な制約になります。
一方、ICカードやRFIDタグのように、専用回路として暗号処理を実装する場合は、回路面積やゲート数も重要になります。

NIST IR 8114では、ハードウェア実装の資源要件は、ゲート面積、ゲート等価数、ロジックブロックなどで表されると説明されています。
また、低コストRFIDタグでは全体で1,000〜10,000ゲート程度しかなく、そのうちセキュリティ用途に使えるのは200〜2,000ゲート程度という例も紹介されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

ここまで小さな世界になると、暗号方式の内部で使う部品の大きさも無視できません。

たとえば、NIST IR 8114では、軽量ブロック暗号で使われる設計上の工夫として、より小さなS-box、単純なラウンド、単純な鍵スケジュール、必要最小限の実装などが紹介されています。
ただし、同時に、小さいブロックサイズや単純な構造には注意点もあり、用途や安全性要件に合わせて考える必要があります。
参考: NIST IR 8114: Report on Lightweight Cryptography

ここでのポイントは、「小さく作れること」と「安全であること」の両方を見る必要があるということです。

2.7 制約は機器単体だけで決まらない

もう一つ大切なのは、軽量暗号が必要かどうかは、機器単体だけで決まるわけではないという点です。

たとえば、センサー自体は小さく、軽量暗号を使う必要があるとします。
そのセンサーからデータを受け取るゲートウェイやサーバーは、十分な性能を持っているかもしれません。

この場合、ゲートウェイやサーバー側も、センサーと通信するために軽量暗号に対応する必要があります。

NIST IR 8114でも、制約のあるセンサーが情報を送る相手である集約装置は、必ずしも制約があるとは限らないものの、センサーが軽量暗号を使うなら相互運用のために対応が必要になると説明されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

この図のように、実際のシステムでは、機器ごとに使う暗号や通信方式が変わる場合があります。
そのため、軽量暗号は「小さな機器だけの話」ではなく、その機器とつながるシステム全体の設計にも関係します。

2.8 この章のまとめ

ここまで見てきたように、IoTや組込み機器では、CPU、RAM、ROM、電力、レイテンシ、回路面積、更新性など、さまざまな制約があります。

軽量暗号は、単に暗号を小さくする技術ではありません。
限られた環境で、必要な安全性を保ちながら、性能や資源のバランスを取るための考え方です。

NIST IR 8114でも、軽量アルゴリズムは弱いという意味ではなく、特定の制約環境に対して、セキュリティ、性能、資源要件のよりよいバランスを目指すものだと説明されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

この章で見た制約を踏まえると、次の章で扱う「軽量暗号とは何か」という定義が自然に見えてきます。

小さな機器でも、暗号は必要です。
しかし、サーバーやPCと同じ前提では考えられない場合があります。

その間を埋めるために考えられてきた分野が、軽量暗号です。

3. 軽量暗号とは何か

前の章では、小さな機器にはCPU、RAM、ROM、電力、レイテンシ、回路面積などの制約があることを見ました。

ここまで来ると、ようやく「軽量暗号とは何か」を自然に説明できます。

軽量暗号は、ざっくり言うと、制約のある機器でも使いやすいように設計された暗号技術です。
ただし、この一文だけだと少し誤解されやすいです。

「軽量」と聞くと、

軽くするために、安全性を少し削った暗号なのかな？

と思うかもしれません。

しかし、軽量暗号をそのように理解すると危険です。
軽量暗号は「弱い暗号」ではなく、限られた資源の中でも、必要な安全性を実現しやすいように設計・評価された暗号技術として見る方が正確です。

NIST IR 8114では、従来のNIST承認暗号標準は汎用コンピュータでよく動くように設計されてきた一方、リソース制約のある小型デバイスでは、既存アルゴリズムを実装できても性能が受け入れられない場合があると説明されています。
参考: NIST IR 8114: Report on Lightweight Cryptography

3.1 「軽量」とは、何が軽いのか

軽量暗号の「軽量」は、1つの意味だけではありません。
機器によって、何を軽くしたいかが変わります。

たとえば、ある機器ではRAM使用量を減らしたいかもしれません。
別の機器では、消費電力を減らしたいかもしれません。
RFIDタグやICカードのような環境では、ハードウェアとして実装したときの回路面積を小さくしたい場合もあります。

整理すると、次のようになります。

「軽い」と言うときの観点	具体的には	関係する機器の例
メモリ使用量が少ない	RAMやROMをあまり使わない	小型マイコン、センサー
処理が軽い	少ない計算量で動く	低性能CPU、低クロックの機器
電力消費が少ない	電池を長持ちさせやすい	電池駆動センサー、ウェアラブル機器
実装サイズが小さい	回路面積やコードサイズを抑えやすい	RFID、ICカード、組込み機器
レイテンシが小さい	短い時間で応答しやすい	車載機器、制御系システム

ここで意識したいのは、すべての観点で同時に最小になる万能な暗号があるわけではない という点です。

ある方式はハードウェアでは小さく実装しやすい一方で、ソフトウェアでは別の方式の方が扱いやすいかもしれません。
また、処理速度を上げるためにテーブルを使うと、ROM使用量が増える場合もあります。

つまり軽量暗号では、「どの環境で、何を優先するのか」を見ながら暗号方式を選ぶ必要があります。

3.2 「軽い」ことと「安全性が低い」ことは違う

軽量暗号で一番避けたい誤解は、軽量暗号 = 安全性を落とした暗号 と考えてしまうことです。

もちろん、暗号方式には安全性・性能・実装コストのトレードオフがあります。
しかし、軽量暗号は「危険でもよいから軽くする」という発想ではありません。

むしろ、制約のある機器でも現実的に暗号を使えるようにすることで、暗号を入れられない状態を避ける ための技術と見ると分かりやすいです。

たとえば、次の2つを比べてみます。

状態	問題
暗号処理が重すぎて小さな機器に入れられない	結果として通信や更新が守れない可能性がある
制約環境向けに設計された標準的な方式を使う	限られた資源の中で、必要な保護を実現しやすい

つまり軽量暗号は、暗号の安全性を軽視するためのものではありません。
小さな機器でも、機密性、完全性、認証といった基本的な保護を現実的に扱えるようにするための考え方です。

NISTの軽量暗号プロジェクトも、既存のNIST暗号標準の性能が受け入れられない制約環境向けに、AEADとハッシュ機能を提供する方式を募集・評価・標準化する流れで進められています。
参考: NIST Lightweight Cryptography Project

💡 豆知識
「軽量」と聞くと、つい「簡易版」「弱い版」のように感じるかもしれません。
しかし軽量暗号の文脈では、むしろ「小さな機器にも暗号技術を届けるための工夫」と考える方が近いです。
キャンプ用の小さな調理器具が、家庭用キッチンの劣化版ではなく、限られた環境に合わせて設計された道具であることに少し似ています。

3.3 軽量暗号で扱うのは「暗号化」だけではない

軽量暗号と聞くと、まず「小さな機器でデータを暗号化する技術」と考えたくなります。
もちろん、暗号化は重要です。

しかし、実際にはそれだけでは足りません。

第1章でも見たように、小さな機器では、センサー値を読まれないようにするだけでなく、操作命令が書き換えられていないか、更新データが本物か、通信相手が正しいかも確認したくなります。

そのため、軽量暗号で重要になる機能には、次のようなものがあります。

機能	やさしく言うと	小さな機器での例
暗号化	データを読まれにくくする	センサー値や設定情報を守る
認証付き暗号	暗号化と改ざん検知をまとめて行う	測定値を隠しつつ、途中の書き換えも検出する
ハッシュ関数	データの指紋を作る	ファームウェア更新データが変わっていないか確認する
MAC	鍵を持つ相手から来たことを確認する	センサーとゲートウェイ間のメッセージ確認
XOF	必要な長さの出力を得る	用途に応じた派生値を作る場合など

特に、近年の軽量暗号では AEAD が重要です。
AEADは Authenticated Encryption with Associated Data の略で、日本語では「関連データ付き認証暗号」などと呼ばれます。

初学者向けには、次のように理解すると分かりやすいです。

AEADは、データを読まれにくくするだけでなく、途中で書き換えられていないかも確認する仕組みです。

たとえば、見守りセンサーが「異常なし」というデータを送るとします。
このデータが盗み見られないことも大切ですが、途中で「異常あり」や「異常なし」に書き換えられてしまうと、通知や対応に影響します。

そのため、小さな機器の通信では、暗号化と改ざん検知をセットで考えることが重要になります。

3.4 NIST標準ではAsconが中心に位置づけられている

軽量暗号の分野では、さまざまな方式が研究・提案されてきました。
その中で、現在の記事として特に押さえておきたいのが Ascon です。

NISTは軽量暗号標準化プロセスを進め、2023年にAsconファミリーを標準化対象として選定しました。
その後、2025年8月に NIST SP 800-232 として、Asconベースの軽量暗号標準を公開しています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

NIST SP 800-232では、次の4つの機能が規定されています。

方式	種類	ざっくりした役割
Ascon-AEAD128	認証付き暗号	データを暗号化し、改ざんも検出する
Ascon-Hash256	ハッシュ関数	データの指紋のような値を作る
Ascon-XOF128	XOF	必要な長さの出力を得る
Ascon-CXOF128	カスタマイズ可能XOF	用途を区別しながら必要な長さの出力を得る

NIST SP 800-232の概要では、AsconファミリーはAEAD、ハッシュ関数、XOFの機能を提供し、IoT機器、組込みシステム、低消費電力センサーのようなリソース制約環境に適していると説明されています。
また、AESが最適に動作しない場合の有力な代替として位置づけられています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

ここでは、Asconの内部構造までは深く扱いません。
重要なのは、軽量暗号が単なる研究用語ではなく、NIST標準として具体的な方式に落とし込まれているという点です。

3.5 軽量暗号を選ぶときの考え方をコード風に見る

軽量暗号は、「IoTだから必ず使う」「AESだから必ず使わない」といった単純なものではありません。
機器の制約、守りたい性質、利用できる標準、実装環境を見ながら判断します。

この考え方を、実装そのものではなく、判断ロジックのイメージとしてC風に書くと次のようになります。

注意: 以下は暗号処理を実装するコードではありません。
実際の製品で暗号方式を選定する場合は、標準仕様、利用ライブラリ、認証要件、脅威モデル、運用条件を確認する必要があります。

#include <stddef.h>
#include <stdbool.h>

typedef enum {
    CRYPTO_PROFILE_GENERAL_PURPOSE,
    CRYPTO_PROFILE_LIGHTWEIGHT
} crypto_profile_t;

typedef struct {
    size_t ram_bytes;          // 機器で利用できるRAMの目安
    size_t rom_bytes;          // ファームウェアに使えるROM/Flashの目安
    bool battery_powered;      // 電池駆動かどうか
    bool needs_aead;           // 暗号化と改ざん検知をまとめて行いたいか
    bool hardware_area_limited;// 回路面積やコストの制約が強いか
} device_constraints_t;

crypto_profile_t select_crypto_profile(device_constraints_t d) {
    // このしきい値は説明用の仮の値です。
    // 実際には、対象機器・標準・ライブラリ・評価結果に基づいて判断します。
    bool strongly_constrained =
        d.ram_bytes < 1024 ||
        d.rom_bytes < 16384 ||
        d.battery_powered ||
        d.hardware_area_limited;

    // 「軽量暗号を選ぶ」=「安全性を下げる」ではない。
    // 制約環境で、必要な保護を現実的に実装するための選択肢として考える。
    if (strongly_constrained && d.needs_aead) {
        return CRYPTO_PROFILE_LIGHTWEIGHT;
    }

    // 十分な資源があり、既存の汎用的な標準方式を問題なく使えるなら、
    // その環境に合った一般的な暗号プロファイルを検討する。
    return CRYPTO_PROFILE_GENERAL_PURPOSE;
}

このコードで伝えたいのは、「軽量暗号は名前だけで選ぶものではない」ということです。

小さな機器だからといって、自動的に軽量暗号を選ぶわけではありません。
逆に、サーバーで一般的な方式が、小さな機器でも問題なく動く場合もあります。

大切なのは、次の順番で考えることです。

その機器は何を守る必要があるのか
どのくらい資源に制約があるのか
どの標準方式・ライブラリが利用できるのか
鍵管理や更新まで含めて運用できるのか

3.6 この章のまとめ

この章では、軽量暗号の基本的な意味を整理しました。

軽量暗号は、単に「小さい暗号」ではありません。
また、「安全性を下げて軽くした暗号」でもありません。

軽量暗号は、IoT機器や組込み機器のように、メモリ、電力、処理性能、実装サイズに制約がある環境でも、必要な暗号機能を現実的に使えるようにするための技術です。

特に近年は、暗号化だけでなく、改ざん検知も一緒に行う認証付き暗号や、ファームウェア更新などにも関係するハッシュ関数が重要になっています。
NIST SP 800-232では、Ascon-AEAD128、Ascon-Hash256、Ascon-XOF128、Ascon-CXOF128が標準として規定されており、制約環境向けの代表的な標準として押さえておきたい内容です。

次の章では、軽量暗号が具体的に何を守るために使われるのかを、機密性、完全性、認証、ファームウェア更新などの観点から整理します。

4. 軽量暗号で守りたいもの

前の章では、軽量暗号が「安全性を下げた暗号」ではなく、制約のある機器でも必要な暗号機能を現実的に使いやすくするための技術だと整理しました。

では、軽量暗号は具体的に何を守るために使われるのでしょうか。

ここで意識したいのは、軽量暗号も、暗号技術全体で見たときの目的は大きく変わらないという点です。
つまり、守りたいものは 機密性、完全性、認証、更新データの正しさ、鍵の安全な扱い などです。

違うのは、それを実現する場所です。
サーバーやPCではなく、小さなセンサー、ICカード、スマートロック、医療機器、車載機器のような、メモリや電力に余裕がない場所で実現しようとするところに、軽量暗号の難しさがあります。

4.1 まず全体像を見る

軽量暗号で守りたいものを、身近な機器の例と対応づけると次のようになります。

守りたいこと	やさしく言うと	小さな機器での例	関係する主な技術
機密性	中身を読まれないようにする	医療センサーの測定値を盗み見られないようにする	暗号化、AEAD
完全性	途中で書き換えられていないか確認する	スマートロックへの操作命令が改ざんされていないか確認する	MAC、AEAD、ハッシュ、署名
認証	本物の相手・機器か確認する	正規のゲートウェイやサーバーから来た命令か確認する	MAC、署名、証明書
更新の安全性	正規の更新データだけを受け入れる	改ざんされたファームウェアを入れない	ハッシュ、デジタル署名
鍵の保護	暗号に使う秘密を守る	機器内の秘密鍵や共有鍵を漏らさない	鍵管理、セキュア領域、更新・失効

図にすると、軽量暗号は次のような位置づけで見ると分かりやすいです。

この章では、それぞれを小さな機器の具体例に置き換えながら見ていきます。

4.2 機密性：センサー値や設定情報を読まれにくくする

機密性は、第三者にデータの中身を読まれないようにする性質です。

たとえば、医療センサーやウェアラブル機器が、心拍数、体温、活動量、睡眠状態のようなデータを扱うとします。
これらは一つ一つのデータ量は小さくても、個人の生活や健康に関係する情報です。

また、スマートホーム機器のセンサー値から、部屋に人がいる時間帯や生活パターンが推測される場合もあります。
温度や照度のような一見何でもないデータでも、組み合わせるとプライバシーに関わることがあります。

このようなデータを通信するときは、必要に応じて暗号化によって中身を読まれにくくします。

ここで軽量暗号が関係するのは、センサー側の資源が限られている場合です。
測定値を守りたい一方で、センサーには大きなメモリや十分な電力がないかもしれません。

そのため、制約のある機器では、少ないメモリや消費電力でも扱いやすい暗号方式が必要になります。

ただし、機密性だけを守れば十分とは限りません。
次に見るように、IoTや組込み機器では「読まれないこと」と同じくらい、「書き換えられていないこと」も重要です。

4.3 完全性：命令や測定値が書き換えられていないか確認する

完全性は、データが途中で勝手に変更されていないことを確認する性質です。

小さな機器では、完全性が特に重要になる場面があります。
なぜなら、IoTや組込み機器では、データが現実世界の動作につながることがあるからです。

たとえば、スマートロックに送る命令を考えます。

LOCK: 鍵を閉める
UNLOCK: 鍵を開ける

この命令が途中で書き換えられると、単なるデータの問題ではなく、実際のドアの開閉に関わります。
医療機器や車載機器、工場の制御機器でも、命令や測定値の改ざんは大きな問題につながる可能性があります。

そのため、暗号化によって中身を隠すだけではなく、途中で書き換えられていないかを確認する仕組みが必要になります。

ここで重要になる代表的な考え方が、AEAD です。
AEADは、Authenticated Encryption with Associated Data の略で、暗号化による機密性に加えて、データや関連データの完全性・真正性を確認する仕組みです。
RFC 5116でも、AEADは多くの暗号アプリケーションで必要になる機密性とメッセージ認証をまとめて扱うものとして説明されています。
参考: RFC 5116: An Interface and Algorithms for Authenticated Encryption

NIST SP 800-232で規定されている Ascon-AEAD128 も、このAEADの方式です。
この標準では、Ascon-AEAD128は128ビット鍵、128ビットnonce、関連データ、平文を入力し、暗号文と128ビット認証タグを出力する方式として定義されています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

初学者向けには、次のように考えると分かりやすいです。

AEADは、データを「封筒に入れて読まれにくくする」だけでなく、封筒が途中で開けられたり、貼り替えられたりしていないかも確認する仕組みです。

処理のイメージを、実装ではなく流れとして書くと次のようになります。

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>

// 注意:
// これはAEAD処理の流れを説明するための疑似コードです。
// 実際の暗号処理を自作するためのコードではありません。
// 製品や実運用では、標準仕様に沿った検証済みライブラリを使う必要があります。

bool receive_command_example(
    const uint8_t *ciphertext, size_t ciphertext_len,
    const uint8_t *tag, size_t tag_len
) {
    uint8_t plaintext_command[16];

    // 1. 受信した暗号文と認証タグを検証する
    //    タグが正しければ、通信内容が改ざんされていない可能性が高いと判断できる
    bool ok = aead_decrypt_and_verify(
        ciphertext,
        ciphertext_len,
        tag,
        tag_len,
        plaintext_command,
        sizeof(plaintext_command)
    );

    // 2. 検証に失敗した場合は、命令を絶対に実行しない
    //    「復号できたように見えるから実行する」は危険
    if (!ok) {
        return false;
    }

    // 3. 検証に成功した場合だけ、命令の中身を解釈する
    //    例: LOCK / UNLOCK などの制御命令を確認する
    return execute_verified_command(plaintext_command);
}

この疑似コードで特に大切なのは、検証に失敗したデータを使わない という点です。
IoT機器では、受け取った命令をそのまま実行すると危険です。
暗号化されているかどうかだけでなく、認証タグや署名の検証に成功したかを確認してから処理する必要があります。

💡 豆知識
暗号化は「中身を見えにくくする」ためのものです。
しかし、IoT機器では「中身が見えないこと」よりも、「命令が勝手に変わっていないこと」の方が重要になる場面もあります。
スマートロックや制御機器では、1ビットの違いが現実世界の動作に影響することがあります。

4.4 認証：本物の機器やサーバーか確認する

認証は、通信相手や送信者が本物であることを確認する性質です。

小さな機器では、次のような確認が必要になる場合があります。

センサーが、本当に正規のゲートウェイへデータを送っているか
ゲートウェイが、本当に登録済みのセンサーからのデータを受け取っているか
スマートロックが、本当に正規のアプリやサーバーからの命令を受け取っているか
機器が、本当にメーカーのサーバーから更新データを受け取っているか

たとえば、攻撃者が偽物のサーバーを用意し、IoT機器をそこにつなげようとする場合を考えます。
機器が相手を確認できなければ、設定情報や測定値を攻撃者へ送ってしまう可能性があります。

反対に、ゲートウェイ側も「このデータは本当に正規のセンサーから来たのか」を確認したい場合があります。
偽物のセンサーが大量のデータを送ってきた場合、異常検知や監視システムの判断に影響するかもしれません。

このような認証には、共有鍵を使うMACや、公開鍵暗号に基づくデジタル署名・証明書などが関係します。
ただし、どの方式を使うかは機器の制約やシステム構成によって変わります。

たとえば、同じメーカーが管理するセンサーとゲートウェイの間では共有鍵ベースの仕組みが使われる場合があります。
一方で、第三者が検証する必要がある更新データや証明書のような場面では、デジタル署名が重要になります。

ここで軽量暗号を考えるうえでのポイントは、認証にもコストがかかるということです。
鍵を保存する場所、署名やMACを計算する時間、通信に追加されるタグや署名のサイズも、制約のある機器では無視できません。

4.5 ファームウェア更新：正規の更新データだけを受け入れる

小さな機器では、ファームウェア更新の安全性も重要です。

ファームウェアは、機器の中で動く基本的なソフトウェアです。
スマートフォンのOS更新ほど目立たないかもしれませんが、IoT機器や組込み機器でも、不具合修正やセキュリティ対策のために更新が必要になることがあります。

ここで問題になるのが、その更新データは本当に正規のものか という確認です。

もし攻撃者が作った偽物のファームウェアを機器が受け入れてしまうと、機器の動作そのものを乗っ取られる可能性があります。
そのため、更新データを受け入れる前に、少なくとも次のような確認が必要になります。

確認したいこと	関係する技術	やさしい説明
ダウンロード中に壊れていないか	ハッシュ関数	更新データの指紋を確認する
途中で改ざんされていないか	ハッシュ、署名	元のデータと違っていないか確認する
正規の作成者が出したものか	デジタル署名	メーカーなどの秘密鍵で署名されたものか確認する
古い版へ戻されていないか	バージョン管理、rollback対策	古い脆弱な版への戻しを防ぐ

NISTの軽量暗号標準に関する解説では、ハッシュはソフトウェア更新が改ざんされていないかを確認する用途にも触れられています。
参考: NIST Finalizes ‘Lightweight Cryptography’ Standard to Protect Small Devices

更新検証の流れを簡略化すると、次のようになります。

疑似コードで書くと、考え方は次のようになります。

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>

// 注意:
// これはファームウェア更新検証の流れを説明する疑似コードです。
// 実際の署名検証やハッシュ計算は、標準仕様に従った実装を使う必要があります。

bool verify_firmware_update(
    const uint8_t *firmware, size_t firmware_len,
    const uint8_t *signature, size_t signature_len,
    uint32_t new_version,
    uint32_t current_version
) {
    uint8_t digest[32];

    // 1. 古いバージョンへ戻す更新ではないか確認する
    //    脆弱性のある古いファームウェアへ戻されると危険
    if (new_version <= current_version) {
        return false;
    }

    // 2. 更新データのハッシュ値を計算する
    //    ハッシュ値は、更新データの「指紋」のようなもの
    hash_256(firmware, firmware_len, digest, sizeof(digest));

    // 3. メーカーなど正規の公開鍵で署名を検証する
    //    検証に失敗した更新データは適用しない
    if (!verify_signature(digest, sizeof(digest), signature, signature_len)) {
        return false;
    }

    // 4. ここまで成功した場合だけ、更新処理へ進む
    return true;
}

ここで意識したいのは、ハッシュだけでは「誰が作った更新データか」までは分からないという点です。
ハッシュはデータの変化を確認する材料になりますが、正規の作成者が出したものかを確認するには、デジタル署名のような仕組みが必要になります。

軽量暗号の記事では、Ascon-Hash256のような軽量ハッシュにも触れますが、ファームウェア更新の安全性はハッシュ関数だけで完結する話ではありません。
署名検証、バージョン管理、失敗時の復旧、更新中の電源断対策など、システム全体で考える必要があります。

4.6 鍵管理：小さな機器でも鍵は小さな問題ではない

暗号技術では、鍵の扱いが非常に重要です。
これは軽量暗号でも変わりません。

むしろ、小さな機器では鍵管理が難しくなる場合があります。

たとえば、次のような課題があります。

課題	具体例
鍵をどこに保存するか	フラッシュメモリに保存するのか、専用の安全な領域を使うのか
製造時にどう鍵を入れるか	工場出荷時に個体ごとの鍵を入れるのか、初回接続時に登録するのか
鍵が漏れたらどうするか	鍵の更新、失効、再登録の仕組みがあるか
すべての機器で同じ鍵を使わないか	1台の漏えいが全体に広がらないようにできるか
乱数をどう用意するか	nonceや鍵生成に必要な乱数を安全に得られるか

ここで特に避けたいのは、すべての機器に同じ秘密鍵を埋め込むような設計です。
もし1台から鍵が取り出されると、同じ鍵を持つ他の機器にも影響が広がる可能性があります。

また、AEADではnonceの扱いも重要です。
nonceは、ざっくり言うと「一度だけ使う値」です。
方式によって要件は異なりますが、同じ鍵のもとでnonceを不適切に再利用すると、安全性に深刻な影響が出る場合があります。

NIST SP 800-232のAscon-AEAD128でも、入力として128ビット鍵と128ビットnonceを使うことが規定されています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

💡 豆知識
nonceは「number used once」に由来する言葉として説明されることがあります。
暗号の世界では、毎回違う値を使うことで、同じメッセージや同じ鍵から危険なパターンが生まれないようにする役割があります。
ただし、nonceに求められる条件は方式によって違うため、仕様書に従う必要があります。

鍵管理を簡単な図にすると、次のようになります。

軽量暗号を使う場合でも、鍵管理が雑であれば安全性は大きく下がります。
暗号方式そのものが軽量で標準化されていても、鍵をソースコードに直接書いたり、全機器で同じ鍵を使ったり、更新手段を用意していなかったりすると、システム全体としては弱くなってしまいます。

4.7 軽量暗号だけで守れる範囲と、守れない範囲

ここまで、軽量暗号が関係する守りたい性質を見てきました。

軽量暗号は、小さな機器で機密性、完全性、認証などを実現するための重要な選択肢です。
しかし、軽量暗号だけでIoTや組込み機器の安全性がすべて決まるわけではありません。

たとえば、軽量暗号は次のようなことには役立ちます。

軽量暗号が役立つこと	例
通信内容を読まれにくくする	センサー値や設定情報の暗号化
通信内容の改ざんを検出する	AEADやMACによるタグ検証
更新データの確認に使う材料を作る	ハッシュ値の計算
小さな機器でも暗号処理を現実的に行う	少ないメモリ・電力での処理

一方で、軽量暗号だけでは次のような問題は解決できません。

軽量暗号だけでは不十分なこと	なぜ不十分か
鍵が漏えいした場合の対応	鍵更新・失効・再登録の仕組みが必要
物理的に機器を分解される攻撃	耐タンパ性やサイドチャネル対策が必要
脆弱なファームウェアを長期間使い続ける問題	安全な更新機構と運用が必要
初期設定パスワードや管理画面の弱さ	認証設計や運用ルールが必要
通信相手を間違える問題	証明書検証や相手認証が必要

つまり、軽量暗号は「小さな機器で暗号を使うための重要な道具」ですが、システム全体の安全性は、暗号方式、鍵管理、実装、通信設計、更新、運用を組み合わせて決まります。

4.8 この章のまとめ

この章では、軽量暗号で守りたいものを整理しました。

小さな機器でも、守りたい性質はサーバーやPCと大きく変わりません。
センサー値や設定情報を読まれないようにする機密性、操作命令や測定値が書き換えられていないかを確認する完全性、本物の機器やサーバーかを確認する認証が重要です。

さらに、IoTや組込み機器では、ファームウェア更新の安全性や鍵管理も大きなテーマになります。
小さな機器は一度設置されると長期間使われることが多く、更新や鍵の入れ替えが難しい場合もあります。

そのため、軽量暗号を理解するときは、単に「軽い暗号方式の名前」を覚えるのではなく、次のように考えると分かりやすいです。

小さな機器で、何を守りたいのか。
そのために、どの暗号機能が必要なのか。
そして、その機器の制約の中で現実的に動かせるのか。

次の章では、ここまで何度か登場した NIST SP 800-232 と Ascon について、もう少し具体的に整理します。
軽量暗号が標準化の中でどのように扱われ、Ascon-AEAD128やAscon-Hash256がどのような役割を持つのかを見ていきます。

5. NIST SP 800-232とAsconの位置づけ

前の章では、軽量暗号で守りたいものを、機密性、完全性、認証、ファームウェア更新、鍵管理という観点から整理しました。

ここまで読むと、次に気になるのは、

では、実際にどの軽量暗号を見ればよいのか？

という点だと思います。

軽量暗号の分野では、さまざまな方式が研究・提案されてきました。
その中で、2026年時点で初学者がまず押さえておきたい重要な標準が、NIST SP 800-232 と、そこで規定されている Ascon です。

この章では、Asconの内部構造や数式には深入りしすぎず、次の3点を中心に整理します。

NIST SP 800-232とは何か
Asconではどのような機能が標準化されたのか
IoTや組込み機器の暗号技術として、どう理解すればよいのか

5.1 NIST SP 800-232とは何か

NIST SP 800-232 は、米国NISTが公開した、制約のあるデバイス向けのAsconベース軽量暗号標準です。
正式なタイトルは、Ascon-Based Lightweight Cryptography Standards for Constrained Devices: Authenticated Encryption, Hash, and Extendable Output Functions です。

NIST SP 800-232は2025年8月に公開され、Asconファミリーを用いて、AEAD、ハッシュ関数、2種類のXOFを規定しています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

ここでのポイントは、Asconが単なる「暗号化方式」だけではないことです。
NIST SP 800-232では、次の4つが標準として規定されています。

方式	種類	ざっくりした役割
Ascon-AEAD128	認証付き暗号	データを暗号化し、改ざんも検出する
Ascon-Hash256	ハッシュ関数	データの指紋のような固定長の値を作る
Ascon-XOF128	XOF	必要な長さの出力を得る
Ascon-CXOF128	カスタマイズ可能XOF	用途を区別しながら、必要な長さの出力を得る

図にすると、次のような位置づけです。

ここで、AEADやXOFという言葉が少し難しく感じるかもしれません。
この記事では、次のように理解すれば十分です。

用語	まず押さえる理解
AEAD	暗号化と改ざん検知をまとめて行う仕組み
ハッシュ関数	データから固定長の指紋のような値を作る仕組み
XOF	必要な長さだけ出力を取り出せる関数
カスタマイズ可能XOF	用途名のような文字列を加えて、用途ごとに出力を分けやすくしたXOF

NIST SP 800-232では、Asconファミリーは制約環境で効率的に動くよう設計されていると説明されています。
また、Ascon-AEAD128は単一鍵設定で128ビットのセキュリティ強度を持つnonceベースAEAD、Ascon-Hash256は256ビットのハッシュを出力し128ビットのセキュリティ強度を持つハッシュ関数、Ascon-XOF128とAscon-CXOF128は最大128ビットのセキュリティ強度を持つXOFとして説明されています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

5.2 なぜNIST標準化が重要なのか

暗号技術では、「自分でよさそうな方式を選んで使う」ことは基本的に避けるべきです。
暗号方式は、見た目のシンプルさや処理速度だけでは安全性を判断できません。

そのため、標準化プロセスや公開レビューを通じて、多くの専門家に評価された方式を使うことが重要になります。

NISTの軽量暗号標準化プロセスでは、2019年に候補方式が提出され、複数ラウンドの評価を経て、2021年に10件のファイナリストが選ばれました。
その後、2023年2月にAsconファミリーを軽量暗号用途向けに標準化する方針が発表されています。
参考: NIST IR 8454: Status Report on the Final Round of the NIST Lightweight Cryptography Standardization Process

流れを簡単にまとめると、次のようになります。

年	出来事
2018年	NISTが軽量暗号候補の募集要件と評価基準を公開
2019年	候補方式が提出され、評価プロセスが進む
2021年	10件のファイナリストが選定される
2023年	Asconファミリーを標準化対象として選定
2025年	NIST SP 800-232としてAsconベースの標準が公開される

ここで注意したいのは、「NISTが標準化したから、どんな使い方でも自動的に安全」という意味ではないことです。

標準化された方式であっても、鍵管理、nonce管理、実装、サイドチャネル対策、ファームウェア更新などを間違えると、安全性は崩れます。

ただし、少なくとも暗号方式そのものについては、公開された評価プロセスを経て選ばれた標準を参照できるため、独自方式を作るよりもはるかに現実的で安全な出発点になります。

💡 豆知識
Asconは、NISTの軽量暗号標準化で突然登場した方式ではありません。
NISTの解説では、Asconは2014年にGraz University of Technology、Infineon Technologies、Radboud Universityの暗号研究者チームによって開発されたと説明されています。
その後、複数ラウンドの公開レビューを経て、NISTの軽量暗号標準の土台として選ばれました。
参考: NIST Finalizes ‘Lightweight Cryptography’ Standard to Protect Small Devices

5.3 Ascon-AEAD128：小さな機器で「隠す」と「改ざん検知」をまとめる

Ascon-AEAD128は、NIST SP 800-232で規定された認証付き暗号です。

前の章でも触れたように、AEADは、データを暗号化して読まれにくくするだけでなく、途中で改ざんされていないかも確認する仕組みです。

Ascon-AEAD128では、暗号化時に次のような入力を使います。

入力	意味	例
`K`	128ビット秘密鍵	センサーとゲートウェイが共有する鍵など
`N`	128ビットnonce	同じ鍵のもとで使い回さない値
`A`	関連データ	機器ID、メッセージ種別、バージョンなど
`P`	平文	センサー値や制御命令など

出力は、暗号文 C と128ビット認証タグ T です。
NIST SP 800-232でも、Ascon-AEAD128の暗号化は128ビット鍵、128ビットnonce、関連データ、平文を入力し、暗号文と128ビットタグを出力すると規定されています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

処理のイメージは次のようになります。

C風の疑似コードで見ると、入力と出力の関係は次のように整理できます。

注意: 以下はAscon-AEAD128の使い方をイメージするための疑似コードです。
実際の暗号処理を自作するためのコードではありません。実運用では、標準仕様に従った検証済みライブラリを使う必要があります。

#include <stddef.h>
#include <stdint.h>
#include <stdbool.h>

#define ASCON_KEY_SIZE   16  // 128ビット = 16バイト
#define ASCON_NONCE_SIZE 16  // 128ビット = 16バイト
#define ASCON_TAG_SIZE   16  // 128ビット = 16バイト

typedef struct {
    uint8_t bytes[ASCON_KEY_SIZE];
} ascon_key_t;

typedef struct {
    uint8_t bytes[ASCON_NONCE_SIZE];
} ascon_nonce_t;

bool send_sensor_value(
    const ascon_key_t *key,
    const ascon_nonce_t *nonce,
    const uint8_t *device_id, size_t device_id_len,
    const uint8_t *sensor_value, size_t sensor_value_len
) {
    uint8_t ciphertext[64];
    uint8_t tag[ASCON_TAG_SIZE];

    // 関連データには、暗号化しないが改ざんされたくない情報を入れる。
    // 例: 機器ID、メッセージ種別、プロトコルバージョンなど。
    const uint8_t *associated_data = device_id;
    size_t associated_data_len = device_id_len;

    // Ascon-AEAD128で平文を暗号化し、同時に認証タグを作る。
    // 実際には、標準仕様に対応したライブラリ関数を利用する。
    bool ok = ascon_aead128_encrypt(
        key->bytes,
        nonce->bytes,
        associated_data,
        associated_data_len,
        sensor_value,
        sensor_value_len,
        ciphertext,
        tag
    );

    // 暗号化に失敗した場合は、データを送信しない。
    if (!ok) {
        return false;
    }

    // 送信時は、暗号文と認証タグを一緒に送る。
    // 受信側はタグ検証に成功した場合だけ復号結果を信頼する。
    return transmit(ciphertext, sensor_value_len, tag, ASCON_TAG_SIZE);
}

この例で大切なのは、関連データ の考え方です。

関連データは、暗号化はしないけれど、改ざんされたくない情報です。
たとえば、機器IDやメッセージ種別は、受信側が通信を処理するために見える形で必要かもしれません。
しかし、そこを書き換えられると別の機器から来たメッセージのように見えたり、別の命令として処理されたりする可能性があります。

AEADでは、このような関連データも認証対象に含めることができます。

5.4 Ascon-Hash256：データの指紋を作る

Ascon-Hash256は、任意長の入力メッセージから256ビットのダイジェストを出力するハッシュ関数です。
NIST SP 800-232では、Ascon-Hash256は256ビットのハッシュを出力し、128ビットのセキュリティ強度を提供すると説明されています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

ハッシュ関数は、データの「指紋」を作る技術です。
軽量暗号の文脈では、たとえば次のような場面で関係します。

場面	ハッシュが関係する理由
ファームウェア更新	更新データが変わっていないか確認する材料になる
ログや測定値の確認	データが後から変わっていないか確認する材料になる
署名の前処理	大きなデータを直接署名するのではなく、ハッシュ値に対して署名する場合がある

処理のイメージは次のようになります。

ただし、ハッシュ関数だけでは「誰が作ったデータか」までは分かりません。
ファームウェア更新のように、正規メーカーが作った更新データか確認したい場合は、ハッシュだけでなくデジタル署名の検証も必要になります。

つまり、Ascon-Hash256は便利な道具ですが、単体で更新の安全性が完成するわけではありません。

5.5 Ascon-XOF128とAscon-CXOF128：必要な長さの出力を得る

Ascon-XOF128とAscon-CXOF128は、XOFに分類されます。
XOFは eXtendable Output Function の略で、必要な長さの出力を得られる関数です。

通常のハッシュ関数は、たとえば「256ビットのハッシュ値を出す」のように出力長が決まっています。
一方、XOFは、必要に応じて出力長を指定できます。

たとえるなら、通常のハッシュ関数は「決まった大きさのコップに水を注ぐ」イメージです。
XOFは「蛇口から必要な量だけ水を出す」イメージに近いです。

機能	出力長	イメージ
Ascon-Hash256	256ビット固定	決まったサイズの指紋を作る
Ascon-XOF128	利用者が指定	必要な長さだけ出力を得る
Ascon-CXOF128	利用者が指定	用途名を加えて、必要な長さだけ出力を得る

Ascon-CXOF128では、カスタマイズ文字列を指定できます。
NIST SP 800-232では、Ascon-CXOF128のカスタマイズ文字列は最大2048ビット、つまり256バイトまでと規定されています。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

カスタマイズ文字列は、ざっくり言えば「この出力は何の用途なのか」を分けるためのラベルのように使えます。

たとえば、同じ入力をもとにしていても、用途ごとに出力を分けたい場合があります。

#include <stddef.h>
#include <stdint.h>

// 注意:
// これはXOFとカスタマイズ可能XOFの使い分けを説明する疑似コードです。
// 実際の鍵導出や乱数生成にそのまま使うコードではありません。

typedef enum {
    OUTPUT_FOR_LOG_ID,
    OUTPUT_FOR_PROTOCOL_LABEL
} output_purpose_t;

void derive_output_example(
    const uint8_t *message, size_t message_len,
    output_purpose_t purpose,
    uint8_t *out, size_t out_len
) {
    if (purpose == OUTPUT_FOR_LOG_ID) {
        // ログ識別子用の出力であることをカスタマイズ文字列で区別する。
        const char customization[] = "log-id";
        ascon_cxof128(message, message_len,
                      (const uint8_t *)customization, sizeof(customization) - 1,
                      out, out_len);
    } else {
        // プロトコル内のラベル用の出力であることを区別する。
        const char customization[] = "protocol-label";
        ascon_cxof128(message, message_len,
                      (const uint8_t *)customization, sizeof(customization) - 1,
                      out, out_len);
    }
}

ここで意識したいのは、XOFを「普通のハッシュ関数とまったく同じもの」として扱わないことです。

NIST SP 800-232では、Ascon-XOF128とAscon-CXOF128は承認済みXOFですが、ハッシュ関数として承認されているわけではないと説明されています。
また、Ascon-Hash256は承認済みハッシュ関数ですが、この標準の中ではHMACでの利用は承認されていません。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

💡 豆知識
XOFは、SHA-3系列で登場するSHAKE128やSHAKE256でも使われる考え方です。
「ハッシュ値は必ず固定長」というイメージを持っていると少し不思議に感じますが、用途によって必要な出力長を変えられる関数として見ると分かりやすくなります。
ただし、どの用途に使ってよいかは標準仕様に従う必要があります。

5.6 AsconはAESの完全な置き換えではない

AsconがNIST標準になったと聞くと、

これからはAESではなくAsconを使えばよいのかな？

と思うかもしれません。

しかし、この理解は少し危険です。

Asconは、AESの完全な置き換えとして理解するよりも、AESなどが最適に動作しにくい制約環境での有力な選択肢 として見る方が正確です。

NISTの解説でも、Asconはリソース制約デバイスのデータ保護に有用な標準として紹介されています。
また、NIST SP 800-232のドラフト説明では、Asconファミリーはコンパクトな状態と複数の暗号機能を持ち、IoT機器、組込みシステム、低消費電力センサーのようなリソース制約環境に適していると説明されています。
参考: NIST Finalizes ‘Lightweight Cryptography’ Standard to Protect Small Devices
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

整理すると、次のようになります。

観点	AESなどの一般的な暗号	Asconなどの軽量暗号
主な利用環境	PC、サーバー、スマートフォンなど	IoT、組込み機器、低消費電力センサーなど
重視されやすい点	高速性、普及度、標準対応、ハードウェア支援	小さな実装、少ないメモリ、低消費電力、制約環境での扱いやすさ
見方	汎用的な標準暗号として重要	制約環境向けの有力な選択肢
注意点	古いモードや設定ミスに注意	鍵管理、nonce管理、物理攻撃対策、標準で承認された用途に注意

ここでは「どちらが強いか」という単純な比較ではなく、どこで、何を守るために、どの制約の中で使うのか を見ることが大切です。

この点は次章であらためて整理します。

5.7 標準化された方式にも、使い方の注意がある

NIST SP 800-232は、Asconベースの軽量暗号を理解するうえで重要な標準です。

ただし、標準化された方式であっても、使い方を間違えると安全性は下がります。

特に、次の点には注意が必要です。

注意点	理由
nonceを不適切に使い回さない	AEADではnonceの扱いが安全性に直結する場合がある
タグ検証に失敗したデータを使わない	改ざんされたデータを受け入れることになる
XOFを通常のハッシュ関数と同一視しない	NIST SP 800-232上の承認用途に従う必要がある
Ascon-Hash256をHMACに使ってよいとは限らない	SP 800-232ではHMACでの利用は承認されていない
方式だけでなく実装も確認する	サイドチャネル攻撃やフォールト攻撃への対策が必要になる場合がある
鍵管理を軽視しない	同じ鍵の使い回しや漏えい時の対応が問題になる

ここで特に初学者が混同しやすいのは、「ハッシュとして使える」「XOFとして使える」「HMACに使える」が同じではないという点です。

Ascon-Hash256は承認済みハッシュ関数です。
しかし、NIST SP 800-232の範囲では、Ascon-Hash256をHMACで使うことは承認されていません。
また、Ascon-XOF128とAscon-CXOF128は承認済みXOFですが、ハッシュ関数として承認されているわけではありません。
参考: NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices

このような注意点を見ると、暗号技術では「名前を知っていること」と「正しく使えること」は別だと分かります。

軽量暗号でも同じです。
Asconという名前を覚えるだけでなく、どの機能を、どの用途で、どの前提のもとで使うのかを確認する必要があります。

5.8 この章のまとめ

この章では、NIST SP 800-232とAsconの位置づけを整理しました。

NIST SP 800-232は、制約のあるデバイス向けのAsconベース軽量暗号標準です。
標準では、Ascon-AEAD128、Ascon-Hash256、Ascon-XOF128、Ascon-CXOF128が規定されています。

Ascon-AEAD128は、データを暗号化し、同時に改ざんも検出するための方式です。
Ascon-Hash256は、データの指紋のような256ビットのダイジェストを作ります。
Ascon-XOF128とAscon-CXOF128は、必要な長さの出力を得るための関数です。

ただし、AsconはAESの完全な置き換えではありません。
PCやサーバーではAESを含む既存の標準暗号が引き続き重要です。
Asconは、AESなどが最適に動作しにくいIoTや組込み機器のような制約環境で、有力な選択肢として理解するのが自然です。

また、標準化された方式であっても、nonce管理、鍵管理、タグ検証、承認された用途の確認、実装上の安全性を無視してよいわけではありません。

次の章では、この流れを受けて、AESとは何が違うのか をもう少し丁寧に整理します。
「AsconとAESはどちらが強いのか」ではなく、「どの環境で何を重視するのか」という観点で見ていきます。

6. AESとは何が違うのか

前章では、NIST SP 800-232とAsconの位置づけを整理しました。
そこで自然に出てくる疑問が、次のものです。

Asconのような軽量暗号が標準化されたなら、これからはAESの代わりにAsconを使えばよいのか？

結論から言うと、そう単純には考えません。

AESは現在も非常に重要な標準的な共通鍵暗号です。
一方で、Asconのような軽量暗号は、IoTや組込み機器のように、メモリ・電力・処理性能・実装サイズに制約がある環境で使いやすいように設計された選択肢です。

つまり、ここで意識したいのは、

どちらが絶対に優れているか

ではなく、

どの環境で、何を守るために、どの制約の中で使うのか

という見方です。

この章では、AESと軽量暗号を対立関係としてではなく、使う場所や前提が違う暗号技術 として整理します。

6.1 まず、AESは今も重要な標準暗号

AESは、Advanced Encryption Standardの略です。
NIST FIPS 197として標準化されている共通鍵暗号で、電子データを保護するために使われる対称鍵ブロック暗号です。

FIPS 197では、AES-128、AES-192、AES-256が規定されており、それぞれ128ビット、192ビット、256ビットの鍵を使います。
また、AESは128ビットのブロックを変換するブロック暗号として定義されています。

参考: NIST FIPS 197 - Advanced Encryption Standard (AES)

ここで押さえたいのは、AESは「古いから不要になった暗号」ではないということです。
サーバー、PC、スマートフォン、通信プロトコル、ストレージ暗号化など、さまざまな場面で今も重要な標準暗号として扱われています。

ただし、AESそのものは ブロック暗号 です。
実際の通信や保存データの保護では、AES単体ではなく、利用モードや認証の仕組みと組み合わせて使われます。

たとえば、AES-GCMは、AESのような承認済みブロック暗号を土台にした認証付き暗号の代表例です。
NIST SP 800-38Dでは、GCMはAEAD、つまり暗号化と認証を扱うモードとして規定されています。

参考: NIST SP 800-38D - Recommendation for Block Cipher Modes of Operation: GCM and GMAC

💡 豆知識
「AESで暗号化する」と言うと、AESだけで通信全体が守られているように聞こえるかもしれません。
しかし実際には、AES-GCMのようなモード、nonce、認証タグ、鍵管理などが組み合わさって安全性を作っています。
暗号では、アルゴリズム名だけでなく「どの使い方をしているか」も大切です。

6.2 AESとAsconは、そもそも見ている環境が違う

AESとAsconを比べるときに、いきなり「どちらが強いか」と考えると分かりにくくなります。

まず見るべきなのは、使われる環境の違い です。

AESは、汎用的なコンピュータ環境で広く使われてきた標準暗号です。
一方、NIST IR 8114では、従来のNIST承認暗号標準は主に汎用コンピュータで性能を発揮するよう設計されてきた一方、リソース制約のある小型デバイスでは、既存方式を実装できない、または実装できても性能が受け入れられない場合があると説明されています。

参考: NIST IR 8114 - Report on Lightweight Cryptography

Asconのような軽量暗号は、まさにこのような制約環境を意識して標準化されています。
NIST SP 800-232は、制約のあるデバイス向けに、AsconベースのAEAD、ハッシュ、XOFを規定した標準です。

参考: NIST SP 800-232 - Ascon-Based Lightweight Cryptography Standards for Constrained Devices

ざっくり整理すると、次のようになります。

観点	AESなどの標準的な共通鍵暗号	Asconなどの軽量暗号
主な利用環境	PC、サーバー、スマートフォン、クラウドなど	IoT機器、組込み機器、RFID、低消費電力センサーなど
重視されやすい点	高速性、普及度、既存システムとの互換性、標準対応	小さな実装、少ないメモリ、低消費電力、制約環境での扱いやすさ
見方	汎用的に広く使われる標準暗号	制約環境向けに設計された選択肢
注意点	利用モード、nonce、鍵管理、古い設定に注意	承認用途、nonce、鍵管理、実装、物理攻撃対策に注意
誤解しやすい点	AESだけで認証まで完結すると思いがち	AESを完全に置き換えるものだと思いがち

この表から分かるように、AESと軽量暗号は、単純に勝ち負けで比較するものではありません。
どちらも暗号技術として重要ですが、重視する条件が違います。

6.3 「強さ」だけでなく「載せられるか」も問題になる

サーバーやPCで暗号方式を選ぶときは、主に安全性、標準対応、処理性能、ライブラリ対応などを考えます。
もちろん、これらはIoTや組込み機器でも大切です。

しかし、小さな機器ではそれに加えて、かなり現実的な問題が出てきます。

たとえば、次のようなことです。

その暗号処理を実行するだけのRAMがあるか
ファームウェアに実装を入れるだけのROMがあるか
電池寿命に影響しすぎないか
応答時間が長くなりすぎないか
ハードウェア実装したときの回路面積が大きすぎないか

つまり、暗号方式は「安全ならそれでよい」だけではなく、その機器に現実的に載せられるか も重要になります。

たとえるなら、AESはしっかりした性能を持つ標準的な工具です。
サーバーやPCのように大きな作業場では、とても使いやすい場面が多いです。

一方で、組込み機器は、小さな工具箱しか持っていない現場のようなものです。
大きな工具が悪いわけではありませんが、限られたスペースや電力の中では、より小さく扱いやすい道具が必要になることがあります。

軽量暗号は、そのような場面で使いやすいように設計された道具だと考えると分かりやすいです。

6.4 AESは「暗号化の部品」、Ascon-AEAD128は「暗号化と確認をまとめた道具」として見る

もう一つ混同しやすい点があります。

AESはブロック暗号です。
一方、NIST SP 800-232で規定されているAscon-AEAD128は、AEAD、つまり認証付き暗号です。

そのため、厳密には、

AESとAscon-AEAD128をそのまま横並びで比較する

よりも、

AESを使ったAEAD方式であるAES-GCMなどと、Ascon-AEAD128を比較する

と考えた方が自然です。

次のコードは、実装用ではなく、考え方を示すための疑似コードです。

// これは説明用の疑似コードです。
// 実際の暗号処理では、標準ライブラリや検証済みライブラリを使います。

// AESそのものは、固定長ブロックを変換する「部品」として見る。
// AES-128では、鍵長は128ビット、ブロック長も128ビットです。
uint8_t key[16];        // 128ビット鍵
uint8_t block[16];      // 128ビットの入力ブロック
uint8_t output[16];     // 128ビットの出力ブロック

aes_encrypt_block(key, block, output);

上のイメージでは、AESは1つのブロックを変換しています。
しかし実際の通信では、長いメッセージを扱ったり、改ざん検知を行ったりする必要があります。

そこで、AES-GCMのような利用モードが使われます。

// これも説明用の疑似コードです。
// AES-GCMは、暗号化と認証タグの生成をまとめて行うAEAD方式です。

uint8_t key[16];          // AES-128用の鍵
uint8_t nonce[12];        // GCMでよく使われる96ビットnonceの例
uint8_t aad[32];          // 暗号化しないが改ざん検知したい関連データ
uint8_t plaintext[64];    // 暗号化したいデータ
uint8_t ciphertext[64];   // 暗号文
uint8_t tag[16];          // 認証タグ

aes_gcm_encrypt(
    key,
    nonce,
    aad,
    sizeof(aad),
    plaintext,
    sizeof(plaintext),
    ciphertext,
    tag
);

Ascon-AEAD128も、同じくAEADとして、暗号化と認証タグの生成をまとめて扱います。

// これも説明用の疑似コードです。
// Ascon-AEAD128は、制約デバイス向けに標準化されたAEAD方式です。

uint8_t key[16];          // Ascon-AEAD128の128ビット鍵
uint8_t nonce[16];        // Ascon-AEAD128の128ビットnonce
uint8_t aad[32];          // 関連データ
uint8_t plaintext[64];    // 暗号化したいデータ
uint8_t ciphertext[64];   // 暗号文
uint8_t tag[16];          // 128ビット認証タグ

ascon_aead128_encrypt(
    key,
    nonce,
    aad,
    sizeof(aad),
    plaintext,
    sizeof(plaintext),
    ciphertext,
    tag
);

この3つの疑似コードから分かるように、AESとAscon-AEAD128は、同じ階層で単純比較すると少しずれます。

AESはブロック暗号という部品です。
AES-GCMは、そのAESを使って暗号化と認証を行うAEAD方式です。
Ascon-AEAD128は、制約環境向けに設計されたAEAD方式です。

そのため、記事内では次のように整理すると誤解しにくくなります。

比較したいもの	より自然な見方
AESとAscon	AESはブロック暗号、Asconは複数機能を持つ軽量暗号ファミリーとして整理する
AESとAscon-AEAD128	階層が少し違うため、単純な横比較は避ける
AES-GCMとAscon-AEAD128	どちらもAEADとして、利用環境や実装制約を比較しやすい

6.5 「AESが使えるならAESでよい」場面もある

軽量暗号を学んでいると、つい「IoTなら軽量暗号を使うべき」と考えたくなるかもしれません。

しかし、これも少し単純化しすぎです。

IoT機器といっても、性能には大きな幅があります。
かなり小さなセンサーもあれば、Linuxが動くような比較的高性能なエッジデバイスもあります。
また、AESを高速に処理するためのハードウェア支援を持つマイコンもあります。

そのため、実際には次のような考え方になります。

つまり、軽量暗号は「IoTだから必ず使うもの」ではありません。
既存の標準暗号を安全に使える環境であれば、それを採用する方が自然な場合もあります。

一方で、RAM、ROM、消費電力、レイテンシ、回路面積などが厳しく、AES-GCMなどの実装が重くなりすぎる場合には、Asconのような軽量暗号が有力な選択肢になります。

この考え方は、NIST IR 8114で示されている「既存のNIST承認アルゴリズムを制約デバイスで使える場合もあるが、性能が受け入れられない場合がある」という整理と対応します。
参考: NIST IR 8114 - Report on Lightweight Cryptography

💡 豆知識
「軽量」という言葉だけを見ると、常に小さい方を選びたくなります。
しかし、暗号方式の選択は登山靴選びに少し似ています。
街中を歩くなら軽い靴が楽ですが、雪山では別の性能が必要です。
暗号も同じで、環境に合った道具を選ぶことが大切です。

6.6 選択を間違えると何が起きるのか

ここまで見ると、AESも軽量暗号も、それぞれに役割があることが分かります。

では、使う環境に合わない選択をすると何が起きるのでしょうか。

たとえば、制約の厳しい機器に重すぎる暗号処理を入れると、次のような問題が起きる可能性があります。

起きること	何が問題になるか
処理が遅い	センサー送信や制御応答が間に合わない
電力を使いすぎる	電池寿命が短くなる
メモリを使いすぎる	他の処理が動かせない、クラッシュする
実装が複雑になる	実装ミスや検証漏れが増える
更新が難しくなる	脆弱性が見つかったときに移行しにくい

一方で、「軽いから」という理由だけで標準化状況や用途を確認せずに方式を選ぶのも危険です。

起きること	何が問題になるか
承認用途と違う使い方をする	期待した安全性や標準適合性を満たさない可能性がある
実装例をそのまま信じる	サイドチャネル対策や乱数処理が不十分な場合がある
nonce管理を軽視する	AEADの安全性が崩れる可能性がある
鍵更新を考えない	漏えい時や長期運用時に被害を抑えにくい

つまり、暗号方式の選択では、次の両方を見る必要があります。

安全性の要件を満たしているか
対象機器の制約の中で安全に実装・運用できるか

どちらか片方だけでは不十分です。

6.7 この章のまとめ

この章では、AESと軽量暗号の違いを整理しました。

AESは、NIST FIPS 197で標準化された重要な共通鍵暗号です。
現在もPC、サーバー、スマートフォン、クラウド、通信プロトコルなど、多くの場面で重要な役割を持っています。

一方で、IoTや組込み機器のような制約環境では、メモリ、電力、処理性能、実装サイズなどが問題になり、既存方式をそのまま使うことが難しい場合があります。
このような場面で、Asconのような軽量暗号が有力な選択肢になります。

ただし、AsconはAESの完全な置き換えではありません。
AES、AES-GCM、Ascon-AEAD128は、それぞれ階層や目的が少し違います。

大切なのは、

何を守りたいのか
どの機器で使うのか
どれくらいのメモリや電力を使えるのか
標準で承認された用途に合っているか
鍵管理やnonce管理まで含めて安全に運用できるか

を確認することです。

次の章では、この流れを受けて、初学者が混同しやすいポイント を先に整理します。
「軽量暗号は弱い暗号なのか」「AsconはAESの完全な代替なのか」といった誤解をほどいてから、最後に安全に使うための注意点へ進みます。

7. 初学者が混同しやすいポイント

この章では、軽量暗号を学ぶときに誤解しやすいポイントを整理します。
ここまでの内容を一度立ち止まって確認し、「軽量暗号をどう理解すればよいか」を言葉にしておきます。

ここまで、IoTや組込み機器で暗号が必要になる理由、小さな機器ならではの制約、軽量暗号の基本、NIST SP 800-232で標準化されたAscon、そしてAESとの違いを見てきました。

ただ、軽量暗号は名前だけ見ると少し誤解されやすい分野です。

「軽量」という言葉から、なんとなく弱そうに見える。
「Asconが標準化されたなら、今後はAESを使わなくなるのか」と感じる。
「IoT機器なら全部軽量暗号を使えばよい」と思ってしまう。

このような誤解を残したままだと、実際に設計や実装を考えるときに判断を間違える可能性があります。
そこでこの章では、初学者が混同しやすいポイントを一つずつ整理します。

7.1 まず全体像を見る

この章で整理する誤解を先にまとめると、次のようになります。

誤解しやすいこと	実際の整理
軽量暗号は弱い暗号である	「安全性を軽くする」のではなく、制約環境で使いやすいように設計された暗号
軽量暗号はAESの完全な代替である	AESを置き換える万能技術ではなく、用途や環境に応じた選択肢
IoT機器は小さいので重要な情報を扱わない	センサー値、操作命令、認証情報、更新データなど重要な情報を扱う場合がある
暗号方式を選べば安全になる	鍵管理、nonce管理、実装、更新、運用まで含めて考える必要がある
暗号化すれば改ざんも防げる	機密性と完全性は別の性質。AEADやMAC、署名が関係する
Asconを使えば自動的に安全になる	標準化された方式でも、使い方や実装を間違えると安全性は下がる
XOFは普通のハッシュ関数と同じ	XOFは任意長出力を得る関数。承認用途や使い方は仕様に従う必要がある
小さい機器は更新しなくてよい	長期運用される機器ほど、更新機構や暗号アジリティが重要になる

図にすると、軽量暗号の理解で大切なのは、次のように「方式名」だけでなく、その周辺まで見ることです。

軽量暗号は、IoTや組込み機器を守るための重要な道具です。
しかし、その道具だけを見ても、システム全体の安全性は判断できません。

7.2 誤解1：軽量暗号は「弱い暗号」なのか

最初に整理したいのが、「軽量」という言葉の意味です。

日本語で「軽い」と聞くと、次のような印象を持つかもしれません。

軽い処理
簡単な仕組み
簡易版
安全性を落としたもの

しかし、軽量暗号における「軽量」は、安全性を軽くする という意味ではありません。
制約のある機器でも使いやすいように、実装サイズ、メモリ使用量、消費電力、処理時間などを意識して設計された暗号、という意味です。

NIST IR 8114では、軽量暗号はリソース制約のあるデバイス向けに調整された暗号分野として扱われています。
また、NISTの軽量暗号プロジェクトも、既存のNIST承認暗号標準が制約環境では受け入れられない性能になる場合を想定して進められました。
参考: NIST IR 8114 - Report on Lightweight Cryptography
参考: NIST Lightweight Cryptography Project

つまり、次のように考えると分かりやすいです。

表現	意味
軽量暗号	制約環境で使いやすいように設計された暗号
弱い暗号	攻撃に対して十分な安全性を持たない暗号
簡易的な独自暗号	十分な検証を受けていない危険な方式になりやすいもの

軽量暗号は、「小さな機器でも安全性を考えるための暗号」です。
「軽いから安全性も軽い」と理解しないように注意が必要です。

💡 豆知識
「軽量暗号」は、アウトドア用の軽量テントに少し似ています。
軽いからといって、雨風を防ぐ役割を捨てているわけではありません。
限られた重さやサイズの中で、必要な機能を実現するために設計されています。

7.3 誤解2：軽量暗号はAESの完全な代替なのか

次に多い誤解は、「Asconが標準化されたなら、今後はAESではなくAsconを使えばよいのか」というものです。

結論から言うと、軽量暗号はAESの完全な置き換えではありません。

AESは、NIST FIPS 197で標準化されている重要な共通鍵暗号です。
また、実際の通信や保存では、AES-GCMのように認証付き暗号として使われることもあります。
参考: NIST FIPS 197 - Advanced Encryption Standard
参考: NIST SP 800-38D - GCM and GMAC

一方、AsconはNIST SP 800-232で、制約のあるデバイス向けの軽量暗号標準として規定されています。
参考: NIST SP 800-232 - Ascon-Based Lightweight Cryptography Standards for Constrained Devices

つまり、両者は単純な上下関係ではなく、使う場所や条件が違います。

観点	AES / AES-GCM	Ascon-AEAD128
位置づけ	広く使われる標準的な共通鍵暗号・認証付き暗号の構成	制約デバイス向けの軽量AEAD
向いている場面	サーバー、PC、スマートフォン、AES支援命令がある環境など	小型IoT機器、組込み機器、低消費電力センサーなど
考えるべきこと	利用モード、鍵管理、nonce管理、ライブラリ設定	鍵管理、nonce管理、実装サイズ、物理攻撃、更新機構
注意点	AES単体ではなく、適切なモードで使う必要がある	AESの全面代替ではなく、制約環境向けの選択肢として見る

たとえるなら、AESは一般的な道路を走る高性能な車、Asconは狭い道や限られた燃料で動くために設計された小型車のようなものです。
どちらが「絶対に上」ではなく、走る場所によって向き不向きがあります。

ここで意識したいのは、「新しい標準が出たから古いものは不要」と短絡しないことです。
暗号方式は、利用環境、実装、運用、標準対応を含めて選ぶ必要があります。

7.4 誤解3：IoT機器は小さいので重要な情報を扱わない

「小さなセンサーなら、そこまで大事な情報はないのでは」と思うかもしれません。
しかし、機器が小さいことと、扱う情報の重要度は別です。

たとえば、温度センサーの値だけを見ると、個人情報には見えないかもしれません。
しかし、複数のセンサー値を長期間集めると、人がいる時間帯、生活パターン、設備の稼働状態などが推測できる場合があります。

また、スマートロックや車載機器、医療機器のように、現実世界の動作に関わる機器では、扱うデータが少量でも影響は大きくなります。

機器	一見すると小さなデータ	実際に問題になり得ること
温度センサー	温度値	在室状況や設備状態の推測
スマートロック	開閉命令	不正解錠、操作履歴の改ざん
見守りセンサー	動きの有無	生活パターンの把握
医療センサー	測定値	誤った判断やプライバシー侵害
工場内センサー	稼働状態	生産状況や異常検知への影響

OWASP IoT Security Verification Standardでは、IoTアプリケーションを、デバイス、通信、クラウド、モバイルアプリなどが関係するエコシステムとして捉える考え方が示されています。
参考: OWASP IoT Security Verification Standard

つまり、IoT機器の安全性は、機器単体の大きさではなく、その機器が何を測り、どこに送信し、どの動作につながるのか で考える必要があります。

7.5 誤解4：暗号化すれば改ざんも防げる

暗号技術を学び始めたときに混同しやすいのが、機密性 と 完全性 です。

機密性は、第三者に中身を読まれないようにする性質です。
完全性は、データが途中で書き換えられていないことを確認する性質です。

この2つは似ているようで、別の性質です。

守りたいこと	やさしく言うと	関係する技術
機密性	中身を読まれない	暗号化
完全性	中身が変わっていない	MAC、署名、AEAD
認証	正しい相手・正しい機器か確認する	MAC、署名、証明書など

たとえば、スマートロックに送る命令を考えます。

命令の中身を読まれないようにしたい
命令が途中で書き換えられていないか確認したい
命令が正規のアプリやサーバーから来たか確認したい

この3つは、似ているようで別の確認です。
そのため、現代の通信では、単に暗号化するだけでなく、AEADのように暗号化と認証をまとめて扱う方式が重要になります。

RFC 5116では、AEADは暗号化された平文の機密性に加え、平文と関連データの完全性を確認する仕組みとして説明されています。
参考: RFC 5116 - An Interface and Algorithms for Authenticated Encryption

軽量暗号でも、この考え方は同じです。
Ascon-AEAD128のようなAEADは、IoT機器の通信で「読まれないこと」と「書き換えを検出すること」をまとめて扱うための選択肢として理解できます。

7.6 誤解5：Asconを使えば自動的に安全になる

Asconは、NIST SP 800-232で標準化された重要な軽量暗号です。
しかし、標準化された方式を選べば、それだけで自動的に安全になるわけではありません。

これは、AESやTLSでも同じです。
強い方式を使っていても、鍵をソースコードに直接書いてしまったり、nonceを固定値にしてしまったり、署名検証を省略したりすれば、安全性は大きく下がります。

たとえば、次のような実装は避ける必要があります。

// 悪い例: nonceを固定値にしてしまっている
// AEADでは、同じ鍵のもとでnonceを再利用しない設計が重要です。
uint8_t nonce[16] = {0};

// 悪い例: 秘密鍵をソースコードに直接埋め込んでいる
// 実際の製品では、鍵の生成・保存・更新・失効を設計する必要があります。
uint8_t key[16] = {
    0x00, 0x01, 0x02, 0x03,
    0x04, 0x05, 0x06, 0x07,
    0x08, 0x09, 0x0a, 0x0b,
    0x0c, 0x0d, 0x0e, 0x0f
};

このコードは、説明のための悪い例です。
実際には、暗号方式そのものを自作するのではなく、標準に従った実装や信頼できるライブラリを使い、鍵管理やnonce管理を含めて設計する必要があります。

NIST SP 800-57 Part 1 Rev.5は、暗号鍵の生成、保存、利用、更新、失効などを含む鍵管理の考え方を整理しています。
参考: NIST SP 800-57 Part 1 Rev.5 - Recommendation for Key Management

また、RFC 5116では、AEADにおいてnonceの重複が安全性に大きく関わることが説明されています。
参考: RFC 5116 - An Interface and Algorithms for Authenticated Encryption

つまり、Asconは重要な標準ですが、次のように理解するのが正確です。

誤解	実際の整理
Asconを使えば安全	Asconは有力な方式だが、使い方と実装が重要
標準化された方式なら設定ミスしても安全	標準方式でも鍵管理やnonce管理を間違えると危険
軽量暗号なら実装も簡単	制約環境では、むしろ実装上の注意が増えることもある

7.7 誤解6：XOFは普通のハッシュ関数と同じなのか

5章で、Ascon-Hash256、Ascon-XOF128、Ascon-CXOF128を紹介しました。
ここで混同しやすいのが、ハッシュ関数とXOFです。

ハッシュ関数は、入力から固定長の出力を作る関数です。
たとえば、Ascon-Hash256は256ビットのダイジェストを出力します。

一方、XOFは Extendable Output Function の略で、必要に応じて任意の長さの出力を得られる関数です。
「出力を伸ばせる関数」と考えると分かりやすいです。

種類	出力長	例	ざっくりした理解
ハッシュ関数	固定長	Ascon-Hash256	決まった長さの指紋を作る
XOF	任意長	Ascon-XOF128	必要な長さの出力を取り出せる
カスタマイズ可能XOF	任意長 + 用途識別	Ascon-CXOF128	用途ごとに分けた出力を得やすい

ただし、ここで注意が必要です。
NIST SP 800-232では、Ascon-Hash256は承認済みハッシュ関数ですが、この標準内ではHMACでの利用は承認されていません。
また、Ascon-XOF128とAscon-CXOF128は承認済みXOFですが、ハッシュ関数として承認されているわけではありません。
参考: NIST SP 800-232 - Ascon-Based Lightweight Cryptography Standards for Constrained Devices

つまり、名前が似ているからといって、自由に置き換えてよいわけではありません。

// 説明用の疑似コードです。
// 「固定長のダイジェストがほしい」のか、
// 「必要な長さの出力を得たい」のかで、使う機能が変わります。

if (need_fixed_256bit_digest) {
    // 固定長の指紋がほしい場合の考え方
    use_ascon_hash256();
} else if (need_variable_length_output) {
    // 任意長の出力がほしい場合の考え方
    use_ascon_xof128();
} else if (need_domain_separation) {
    // 用途ごとに出力を分けたい場合の考え方
    use_ascon_cxof128_with_custom_string();
}

実際の実装では、仕様書と利用するライブラリのドキュメントを確認し、承認されている用途に従う必要があります。

💡 豆知識
XOFは、蛇口から必要な量だけ水を出すようなイメージで説明されることがあります。
ただし、「必要なだけ出せる」からといって、どの用途にも自由に使えるわけではありません。
暗号では、出力の使い道や用途分離がとても重要です。

7.8 誤解7：小さな機器は更新しなくてよい

IoT機器や組込み機器は、一度設置すると長く使われることがあります。
家庭の中に置かれたセンサー、工場の設備、車載機器、医療機器などは、数年単位で運用されることも珍しくありません。

ここで問題になるのが、暗号技術やセキュリティ設定は時間とともに見直しが必要になる、という点です。

暗号方式そのものに問題が見つかる場合もあります。
実装ライブラリに脆弱性が見つかる場合もあります。
鍵が漏えいしたり、証明書の有効期限が切れたりする場合もあります。

そのため、小さな機器でも、更新機構や移行計画を考える必要があります。

観点	考えること
ファームウェア更新	正規の更新だけを受け入れるか
ロールバック対策	古い脆弱なバージョンに戻されないか
鍵更新	漏えい時に鍵を更新・失効できるか
暗号方式の変更	将来、別の方式へ移行できるか
長期運用	何年使う機器なのか、いつまで保守するのか

この考え方は、暗号アジリティ とも関係します。
暗号アジリティとは、暗号方式や鍵長、ライブラリ、設定などを、必要に応じて変更しやすくしておく考え方です。

軽量暗号も、選んだら終わりではありません。
小さな機器ほど更新が難しいこともあるため、設計段階から「将来どう変えるか」を考えておくことが大切です。

7.9 迷ったときの考え方

ここまでの誤解を踏まえると、軽量暗号を学ぶときや使うときは、次の順番で考えると整理しやすくなります。

判断の流れを、説明用の疑似コードとして書くと次のようになります。

// 説明用の疑似コードです。
// 実際の暗号方式選定では、標準、ライブラリ、製品要件、脅威モデルを確認します。

bool should_consider_lightweight_crypto(Device device, SecurityGoal goal) {
    // まず、守りたいものがあるかを確認する
    if (!goal.requires_confidentiality &&
        !goal.requires_integrity &&
        !goal.requires_authentication) {
        return false;
    }

    // 次に、機器の資源制約を確認する
    if (device.has_enough_cpu &&
        device.has_enough_ram &&
        device.has_enough_power_budget) {
        // 十分な資源があるなら、AES-GCMなど既存の標準方式も候補になる
        return false;
    }

    // 資源制約が厳しく、既存方式の性能や実装サイズが問題になるなら、
    // Asconなどの軽量暗号を検討する価値がある
    return true;
}

もちろん、この疑似コードだけで実際の暗号方式を決めることはできません。
しかし、軽量暗号を考えるときに、いきなり方式名から入るのではなく、守りたいもの、機器の制約、標準、運用 の順に考えることが大切です。

7.10 この章のまとめ

この章では、軽量暗号を学ぶときに混同しやすいポイントを整理しました。

軽量暗号は、弱い暗号ではありません。
制約のある機器でも暗号技術を使いやすくするための設計です。

また、AsconはAESの完全な置き換えではありません。
AESやAES-GCMが適している場面もあれば、Asconのような軽量暗号が適している場面もあります。

そして、暗号方式を選んだだけでは安全になりません。
鍵管理、nonce管理、実装、サイドチャネル攻撃、ファームウェア更新、暗号アジリティまで含めて考える必要があります。

軽量暗号を理解するときは、方式名だけを見るのではなく、次の4つをセットで考えると整理しやすくなります。

何を守りたいのか
どのような制約があるのか
どの暗号機能を使うのか
どう安全に実装・運用するのか

次の章では、軽量暗号を実際に使うときに一緒に考えるべき注意点を整理します。
方式名の誤解をほどいたうえで、鍵管理、nonce管理、更新、長期運用といった周辺設計へ進みます。

8. 軽量暗号だけで安全になるわけではない

ここまでで、軽量暗号が「小さな機器でも暗号技術を使いやすくするための選択肢」であることを見てきました。
また、前の章では「軽量暗号は弱い暗号ではない」「AsconはAESの完全な置き換えではない」といった誤解も整理しました。

特にAsconは、NIST SP 800-232で制約デバイス向けの軽量暗号標準として規定されており、IoT機器、組込み機器、低消費電力センサーのような環境で有力な選択肢になります。

ただし、ここで一度立ち止まる必要があります。

軽量暗号を使えば、IoT機器が自動的に安全になるわけではありません。

これは軽量暗号に限らず、暗号技術全般に言えることです。
どれだけ標準化された方式を使っていても、鍵の扱いを間違えたり、nonceを再利用したり、ファームウェア更新の検証を省略したり、物理的な攻撃を考えていなかったりすると、安全性は大きく下がります。

たとえるなら、軽量暗号は「小さな機器にも入れやすい丈夫な鍵」のようなものです。
しかし、その鍵を玄関マットの下に置いたり、同じ鍵を全世帯で使い回したり、鍵穴以外の窓を開けっぱなしにしていたら、家全体は安全とは言えません。

この章では、軽量暗号を使うときに一緒に考えるべきことを整理します。

8.1 まず全体像を見る

軽量暗号は、IoT機器の安全性を支える重要な部品です。
しかし、IoT機器の安全性は、暗号方式だけで決まるわけではありません。

NIST SP 800-232では、AsconファミリーがAEAD、ハッシュ、XOFを提供し、IoT機器や組込みシステム、低消費電力センサーのようなリソース制約環境に適した方式として説明されています。
参考: NIST SP 800-232 - Ascon-Based Lightweight Cryptography Standards for Constrained Devices

一方で、OWASPのIoT Security Verification Standardでは、IoTアプリケーションは複数の相互接続された要素からなる複雑なエコシステムであり、IoTの安全性は組込みアプリケーションだけでなく、その周囲のエコシステムを含めて考える必要があると説明されています。
参考: OWASP IoT Security Verification Standard

つまり、軽量暗号は重要ですが、見るべき範囲はそれだけではありません。

8.2 鍵管理：暗号方式より先に崩れやすい部分

暗号技術では、アルゴリズムそのものに注目しがちです。
しかし、実際には 鍵管理 が非常に重要です。

鍵管理とは、暗号鍵を生成し、保存し、使い、更新し、不要になったら失効・削除するまでの一連の扱いを指します。

たとえば、次のような状態だと、強い暗号方式を使っていても危険です。

よくない例	何が問題か
すべての機器に同じ鍵を入れる	1台から鍵が漏れると、他の機器にも影響する可能性がある
鍵をファームウェア内にそのまま書く	解析されたときに鍵が抜き出される可能性がある
鍵を一度も更新しない	長期運用中の漏えいや退役時のリスクに対応しにくい
鍵の用途を分けない	通信用、更新用、保存用の鍵が混ざり、被害範囲が広がる
鍵が漏れたときの失効手段がない	漏えい後も攻撃者が使い続けられる可能性がある

NIST SP 800-57 Part 1 Rev.5は、暗号鍵の管理に関する一般的なガイダンスとベストプラクティスを扱う資料です。
この資料では、鍵管理には鍵材料の管理、鍵の保護、鍵管理機能、暗号を使う際に考えるべきさまざまな課題が含まれると説明されています。
参考: NIST SP 800-57 Part 1 Rev.5 - Recommendation for Key Management

軽量暗号を使う場合でも、この考え方は変わりません。
むしろ、IoT機器は数が多く、現場に設置されたまま長期間使われることが多いため、鍵の配布・更新・失効をどう設計するかが重要になります。

たとえば、説明用にかなり単純化すると、鍵の用途分離は次のように考えられます。

// 説明用の疑似コードです。
// 実際の製品では、鍵の生成・保存・保護は専用のセキュア領域やKMS等を含めて設計します。

typedef enum {
    KEY_FOR_COMMUNICATION,   // センサー値などの通信を保護する鍵
    KEY_FOR_FIRMWARE_UPDATE, // ファームウェア更新の検証に使う鍵
    KEY_FOR_LOCAL_STORAGE    // 機器内に保存するデータを守る鍵
} KeyPurpose;

Key get_key_for_purpose(KeyPurpose purpose) {
    // 用途ごとに異なる鍵を取り出すイメージ。
    // 1つの鍵を何にでも使い回すと、漏えい時の影響範囲が広がる。
    switch (purpose) {
        case KEY_FOR_COMMUNICATION:
            return load_communication_key();
        case KEY_FOR_FIRMWARE_UPDATE:
            return load_update_verification_key();
        case KEY_FOR_LOCAL_STORAGE:
            return load_storage_key();
        default:
            return KEY_ERROR;
    }
}

このコードは、実用的な暗号実装ではありません。
ここで伝えたいのは、鍵は用途ごとに分けて考える必要がある という点です。

💡 豆知識
暗号方式を選ぶことは「どの金庫を買うか」に近いです。
一方、鍵管理は「その金庫の鍵を誰が持ち、どこに保管し、失くしたときにどうするか」に近いです。
実際に事故が起きやすいのは、金庫そのものより鍵の扱いだったりします。

8.3 nonce管理：一度だけ使う値をどう扱うか

AEADを使うときに特に注意したいのが、nonce です。
nonceは、ざっくり言うと「同じ鍵のもとで、暗号化のたびに変える値」です。

Ascon-AEAD128でも、入力として鍵、nonce、関連データ、平文を使います。
nonceそのものは秘密である必要はありませんが、同じ鍵のもとで同じnonceを使い回すと危険になる場合があります。

RFC 5116では、AEADの安全性にとって、固定された鍵に対して認証付き暗号化の各呼び出しでnonce値が異なるように構成することが重要だと説明されています。
参考: RFC 5116 - An Interface and Algorithms for Authenticated Encryption

説明用に、よくない例と改善イメージを比べてみます。

// 悪い例: nonceを固定値にしてしまう
// 同じ鍵と同じnonceの組み合わせを何度も使う可能性があり、AEADの安全性を壊す原因になる。

uint8_t fixed_nonce[16] = {0};

aead_encrypt(key, fixed_nonce, associated_data, plaintext, ciphertext, tag);

上のように、nonceを毎回ゼロにするような実装は避けるべきです。
改善の方向としては、メッセージごとに値が変わるカウンタや、適切な乱数生成を使って、同じ鍵のもとでnonceが重複しないように設計します。

// 改善イメージ: メッセージごとにカウンタを進めてnonceを作る
// 実際には、電源断や再起動後にも値が巻き戻らないように、永続化の設計が必要。

uint64_t message_counter = load_counter_from_nonvolatile_memory();

uint8_t nonce[16];

// nonceの前半に機器ID、後半にメッセージカウンタを入れるイメージ。
// これは説明用であり、実際には採用方式の仕様・プロトコル設計に従う必要がある。
make_nonce_from_device_id_and_counter(device_id, message_counter, nonce);

aead_encrypt(key, nonce, associated_data, plaintext, ciphertext, tag);

// 次回同じnonceを使わないように、カウンタを進めて保存する。
message_counter++;
save_counter_to_nonvolatile_memory(message_counter);

ここで難しいのは、IoT機器では電源が突然切れたり、電池交換で再起動したりすることがある点です。
カウンタが巻き戻ると、過去と同じnonceを使ってしまう可能性があります。

そのため、nonce管理は単なる変数の話ではなく、保存領域、再起動、エラー処理、製造時の初期化まで含む設計になります。

8.4 リプレイ攻撃：正しい命令でも「もう一度使われる」と困る

AEADで暗号化と改ざん検知を行っていても、それだけで過去のメッセージの再送を完全に防げるとは限りません。

たとえば、スマートロックに対して、正規の利用者が過去に送った「ドアを開ける」という命令を攻撃者が記録していたとします。
その命令が暗号化され、認証タグも正しかったとしても、後から同じメッセージを再送されると困る場合があります。

このような攻撃を リプレイ攻撃 と呼びます。

リプレイ攻撃への対策としては、タイムスタンプ、カウンタ、nonce、チャレンジレスポンスなどを組み合わせることがあります。

対策の考え方	やさしい説明	注意点
カウンタ	メッセージ番号を増やして古い番号を拒否する	カウンタの保存・巻き戻り対策が必要
タイムスタンプ	有効期限を短くする	機器の時刻同期が必要
チャレンジレスポンス	毎回違う問いに答えさせる	プロトコル設計が必要
nonce	使い回しを避ける値を入れる	生成・保存・重複回避が必要

ここでも重要なのは、「暗号化されているから安全」と考えないことです。
メッセージが本物でも、いつ使われたものか を確認できないと危険な場合があります。

8.5 ファームウェア更新：正規の更新だけを受け入れる

IoT機器では、出荷後にファームウェア更新が必要になることがあります。
脆弱性の修正、機能改善、設定変更などのためです。

しかし、更新の仕組みが弱いと、攻撃者が用意した不正なファームウェアを機器に入れられる可能性があります。
そのため、更新時には少なくとも次のような確認が重要になります。

ファームウェア更新では、ハッシュ関数やデジタル署名が重要になります。
ハッシュ関数は更新データが変わっていないかを確認する材料になり、デジタル署名は正規の発行者が出した更新かを確認する材料になります。

NISTの軽量暗号標準に関する解説でも、ハッシュはデータの指紋のように働き、ソフトウェア更新時にマルウェアが紛れ込んでいないか確認する用途に触れられています。
参考: NIST Finalizes ‘Lightweight Cryptography’ Standard to Protect Small Devices

ただし、ここでも「ハッシュだけ」では不十分です。
ハッシュ値も攻撃者が差し替えられるなら、正規の更新かどうかは確認できません。
そのため、正規の秘密鍵で署名された更新だけを受け入れる、といった設計が必要になります。

さらに、古いが正規に署名されたファームウェアへ戻される ロールバック攻撃 にも注意が必要です。
古いバージョンに既知の脆弱性がある場合、署名が正しくても安全とは限らないため、バージョン番号や更新履歴も確認する必要があります。

8.6 サイドチャネル攻撃：機器から漏れる「気配」を読む攻撃

IoT機器や組込み機器では、攻撃者が物理的に機器へ近づける場合があります。
このとき問題になりやすいのが、サイドチャネル攻撃 です。

サイドチャネル攻撃とは、暗号アルゴリズムの数式そのものを直接破るのではなく、実装が動くときに出る情報を観察して秘密情報を推測する攻撃です。

たとえば、次のような情報が手がかりになることがあります。

観察される情報	攻撃のイメージ
処理時間	鍵の値によって処理時間が変わるなら、そこから推測する
消費電力	暗号処理中の電力変化から内部状態を推測する
電磁波	機器から出る電磁的な漏えいを観察する
エラーの出方	故障注入やエラー応答から秘密情報を推測する

NISTの軽量暗号標準化の提出要件では、タイミング攻撃、単純・差分電力解析、単純・差分電磁波解析などに対する対策を実装しやすいことが評価上の観点に含まれていました。
参考: NIST - Submission Requirements and Evaluation Criteria for the Lightweight Cryptography Standardization Process

また、NISTのAscon標準に関する解説では、どの暗号アルゴリズムもサイドチャネル攻撃に本質的に免疫があるわけではない一方、Asconは多くの従来方式よりサイドチャネル耐性実装を支援しやすい設計だと説明されています。
参考: NIST Finalizes ‘Lightweight Cryptography’ Standard to Protect Small Devices

つまり、Asconを使うことは有力な選択肢ですが、方式を選ぶだけで物理攻撃に自動的に強くなるわけではありません。
実装方法、マスキング、乱数、エラー処理、ハードウェア設計まで含めて考える必要があります。

💡 豆知識
サイドチャネル攻撃は、金庫そのものをこじ開けるというより、金庫を開ける人の手元の音や動き、かかった時間から番号を推測するようなイメージです。
暗号方式が強くても、実装から出る「気配」がヒントになってしまうことがあります。

8.7 長期運用：出荷して終わりではない

IoT機器は、一度設置されると長期間使われることがあります。
家庭内のセンサー、工場の設備、車載機器、医療機器などでは、数年単位で使われることも珍しくありません。

このとき問題になるのが、長期運用中に暗号の前提が変わること です。

長期運用で起きること	考えるべきこと
暗号方式の推奨が変わる	将来の移行先を検討できる設計にする
脆弱性が見つかる	ファームウェア更新の仕組みを用意する
鍵が漏えいする	鍵更新・失効・再登録の仕組みを用意する
機器が中古流通・廃棄される	初期化や秘密情報の削除を考える
サーバー側のAPIが変わる	古い機器との互換性と安全性を考える

ここで関係するのが、暗号アジリティ です。
暗号アジリティとは、暗号方式、鍵長、設定、ライブラリなどを、必要に応じて交換・更新しやすくしておく考え方です。

軽量暗号を採用するときも、「今この機器で動くか」だけではなく、「5年後、10年後に更新できるか」を考える必要があります。

8.8 最低限確認したいチェックリスト

軽量暗号をIoT機器に使う場合、少なくとも次のような観点を確認したいです。

観点	確認したいこと
目的	機密性、完全性、認証のどれを守るために使うのか
方式	標準化された方式を、承認された用途で使っているか
鍵管理	鍵の生成、保存、更新、失効を設計しているか
nonce管理	同じ鍵のもとでnonceが再利用されない設計か
乱数	必要な場面で十分な乱数を用意できるか
更新	ファームウェア更新時に署名検証を行うか
リプレイ対策	古いメッセージを再送されても拒否できるか
物理攻撃	サイドチャネルや故障注入への対策を考えているか
ログ	異常な通信や更新失敗を追跡できるか
移行	暗号方式や鍵長を将来変更できるか

この表を見ると、軽量暗号はあくまで全体の一部だと分かります。
軽量暗号を選ぶことは大切ですが、それを安全に使い続けるための設計も同じくらい重要です。

8.9 この章のまとめ

この章では、軽量暗号を使えばIoT機器が自動的に安全になるのか、という点を整理しました。

Asconのような標準化された軽量暗号は、制約のある機器で暗号技術を使ううえで重要な選択肢です。
しかし、実際の安全性は暗号方式だけでは決まりません。

特に、次の点が重要です。

鍵をどのように生成・保存・更新・失効するか
AEADで使うnonceを再利用しないように設計できているか
古いメッセージの再送を防げるか
正規のファームウェア更新だけを受け入れるか
サイドチャネル攻撃や物理攻撃を考えているか
長期運用中に暗号方式を変更できるか

軽量暗号は「小さな機器に暗号を入れるための強力な道具」です。
ただし、その道具を安全に使うには、鍵管理、実装、更新、運用まで含めて考える必要があります。

次の章では、この記事全体をまとめます。
小さな機器にも暗号が必要になる理由から、Asconの位置づけ、そして安全に使うための注意点までを振り返ります。

9. まとめ

最後に、本記事で整理してきた内容を振り返ります。
軽量暗号では、「どの暗号方式を使うか」だけでなく、「どのような制約の中で、何を守り、どう運用するか」まで考えることが大切です。

本記事では、スマートロック、センサー、ICカード、医療機器のような身近な小さな機器を入口にして、軽量暗号の考え方を整理しました。

小さな機器であっても、データを送ったり、命令を受け取ったり、ファームウェアを更新したりします。
そのため、通信内容を盗み見られないこと、データが途中で書き換えられていないこと、本物の相手とやり取りしていることを確認する必要があります。

一方で、IoT機器や組込み機器には、CPU、RAM、ROM、電力、処理時間、回路面積などの制約があります。
このような制約の中で、必要な安全性と実装しやすさのバランスを取るために考えられてきた分野が、軽量暗号です。

9.1 なぜ軽量暗号が必要なのか

PCやサーバーのように計算資源に比較的余裕がある環境では、既存の暗号方式やライブラリを使いやすい場面が多くあります。

しかし、すべての機器が同じ余裕を持っているわけではありません。

たとえば、小さなセンサーやRFIDタグ、電池で長期間動く機器では、次のような制約が問題になります。

制約	軽量暗号で意識したいこと
RAM	大きなバッファや作業領域を置きにくい
ROM・Flash	実装コードやテーブルのサイズを大きくしにくい
電力	暗号処理が電池寿命に影響する
処理時間	制御機器では遅延が問題になる場合がある
回路面積	ハードウェア実装ではゲート数や面積が制約になる
更新性	長期間使う機器では、将来の方式変更も考える必要がある

ここで大切なのは、軽量暗号が「安全性を軽くする暗号」ではないという点です。

軽量暗号は、限られた資源の中で暗号技術を現実的に使うための選択肢です。
言い換えると、暗号化や認証をあきらめるためのものではなく、制約のある機器でも必要な保護を実装しやすくするための考え方です。

9.2 軽量暗号では何を選択肢として見るのか

本記事では、軽量暗号の代表的な標準化動向として NIST SP 800-232 と Ascon を扱いました。

NIST SP 800-232は、制約のあるデバイス向けのAsconベース軽量暗号標準です。
この標準では、Ascon-AEAD128、Ascon-Hash256、Ascon-XOF128、Ascon-CXOF128が規定されています。

参考: NIST SP 800-232 - Ascon-Based Lightweight Cryptography Standards for Constrained Devices

ただし、ここで注意したいのは、Asconを「AESの完全な置き換え」と見ないことです。

AESは現在も重要な標準的な共通鍵暗号であり、多くの環境で使われています。
AES-GCMのような認証付き暗号が適している場面もあります。

一方で、AESをそのまま使うには厳しい制約環境では、Asconのような軽量暗号が有力な選択肢になります。

つまり、重要なのは次のように考えることです。

AESかAsconかを単純に優劣で見る
ではなく、
機器の制約・守りたい性質・実装環境・運用要件に合わせて選ぶ

図にすると、次のようなイメージです。

💡 豆知識
軽量暗号は「通常の暗号より偉い」「新しいから必ず良い」という話ではありません。
キャンプ用の小さな調理器具が便利な場面もあれば、家庭のキッチンでは普通の調理器具の方が使いやすい場面もあります。
暗号方式も同じで、使う場所に合っているかが大切です。

9.3 軽量暗号はIoTセキュリティ全体の一部

もう一つ大切なのは、軽量暗号だけでIoT機器全体が安全になるわけではないという点です。

軽量暗号は、制約のある機器でデータの機密性や完全性、認証を実現するための重要な部品です。
しかし、実際のIoT機器では、暗号方式の選択だけでなく、鍵管理、nonce管理、ファームウェア更新、物理攻撃、長期運用まで含めて考える必要があります。

たとえば、Ascon-AEAD128のような認証付き暗号を使っていても、鍵をソースコードに直接書いてしまったり、nonceを毎回同じ値にしてしまったり、古いファームウェアへ戻せてしまったりすると、安全性は大きく下がります。

対策	主に考えること
軽量暗号	制約のある機器で暗号化・認証・改ざん検知を行う
鍵管理	鍵をどこで生成し、どこに保存し、漏えい時にどう更新するか
nonce管理	AEADで同じ鍵とnonceの組み合わせを使い回さないようにする
ファームウェア更新	更新ファイルの署名検証やロールバック対策を考える
サイドチャネル対策	電力、処理時間、電磁波などから秘密が漏れないようにする
暗号アジリティ	将来、方式や鍵長を変更できるようにしておく
運用	長期稼働する機器をどう更新・監視・廃棄するか

このように見ると、軽量暗号はIoTセキュリティの中心的な部品の一つですが、全体の一部でもあります。

セキュリティでは、1つの対策にすべてを任せるのではなく、複数の対策を重ねることが大切です。
軽量暗号も、その多層防御の中で使われる技術として考えると理解しやすくなります。

9.4 本記事の要点

最後に、本記事の要点を短くまとめます。

よくある考え方	注意点
小さな機器なら暗号は不要	小さな機器でもデータ、命令、更新ファイルを扱うため保護が必要
軽量暗号は弱い暗号	弱いという意味ではなく、制約環境向けに設計された暗号技術
Asconを使えばIoT機器は安全	鍵管理、nonce管理、実装、更新、物理攻撃対策も必要
AsconはAESの完全な置き換え	AESとは利用環境や役割を見て使い分ける
暗号化していれば十分	完全性、認証、更新検証、運用まで含めて考える必要がある
標準化された方式なら自動的に安全	使い方や実装を誤ると安全性は下がる
一度実装すれば終わり	長期運用では更新、監視、方式移行も考える必要がある

この記事で特に伝えたいことは、次の一文です。

軽量暗号では、「軽い暗号方式を選ぶこと」だけでなく、制約のある機器で何を守り、どのように安全に使い続けるかを考える必要がある。

そのため、Asconのような標準化された軽量暗号を知ることは重要ですが、それだけで終わりではありません。
機器の制約、守りたいデータ、鍵管理、nonce管理、更新、長期運用まで含めて整理することが大切です。

9.5 最後に

本記事では、暗号技術の中でも「軽量暗号」と「IoT・組込み機器における制約」に絞って説明しました。

ただし、実際のサービスや機器では、軽量暗号だけでなく、共通鍵暗号、認証付き暗号、ハッシュ関数、デジタル署名、鍵管理、TLS、ファームウェア更新、暗号アジリティなど、さまざまな技術や考え方が組み合わされています。

暗号技術は、単語だけを見ると難しく感じます。
しかし、「何を守るための技術なのか」「どの環境で使われるのか」「どの制約の中で使うのか」「ほかの技術とどう組み合わせるのか」に分けると、少しずつ整理しやすくなります。

この記事が、スマートロックやセンサーのような小さな機器の裏側で暗号技術がどのように使われているのか、そして軽量暗号を安全に使うための考え方を理解する入口になればうれしいです。