〈一般研究課題〉 携帯端末における認証暗号の実装性能評価
助 成 研 究 者

名古屋大学

岩田哲

携帯端末における認証暗号の実装性能評価
岩田 哲（名古屋大学）

Evaluation of Implementation Characteristics ofAuthenticated Encryption on Mobile Devices
Tetsu Iwata(Nagoya University)

Abstract：
An authenticated encryption scheme is a symmetric key cryptographic primitive thatsimultaneously provides confidentiality and integrity of input data. The scheme has wide
applications, and some of them are heavily used in our daily lives. CAESAR (Competition for
Authenticated Encryption: Security, Applicability, and Robustness), initiated in 2014, categorizes
the use case of authenticated encryption schemes into Use Case 1 (lightweight applications,resource constrained environments), Use Case 2 (high-performance applications), and Use Case 3(defense in depth). The project was completed with the announcement of the final portfolio inFebruary, 2019. In this study, we focus on the six CAESAR 3rd round candidates in Use Case 1.
These are CLOC, SILC, Jambu, Ketje, Ascon, and ACORN. We evaluate the implementation
characteristic of these schemes on real mobile devices. Given that mobile devices are equipped witha battery, we focus on the energy consumption of these schemes. We use five Android mobiledevices to see their energy consumption. We implement six authenticated encryption schemes basedon the reference code provided by the designers on five mobile devises, and we use both hardware
and software tools to obtain the figures. As a result, our implementation figures show that CLOC,SILC, Jambu, and Ascon perform better with this order, followed by Ketje or ACORN dependingon the input length.

－ 61 －1. はじめに
認証暗号技術は，コンピュータやネットワーク上のデータの秘匿と認証を同時に行うための共通鍵暗号技術であり，これまでに数多くの方式が設計され，そのいくつは実際に身の回りの様々な場面で活用されている．ネットワークとコンピュータの応用範囲の拡大やIoTデバイスの普及に従い，その活用範囲はますます拡大しており，安全であり，なおかつ優れた実装性能を有する認証暗号技術の開発が望まれている．
現在広く利用されているGCM（Galois/Counter Mode）[1]やCCM（Counter with CBC-MAC）[2]といった方式には安全性と効率の面で改善可能であることが知られている．2014年に始められた
CAESAR（Competition for Authenticated Encryption: Security, Applicability, and Robustness）[3]は，GCMに代わる優れた認証暗号技術を選定するための国際的な公募プロジェクトであり，認証暗号技術の研究，開発は活発に進められている．CAESARでは認証暗号の利用環境に応じて，UseCase 1（軽量アプリケーション），Use Case 2（高性能アプリケーション），Use Case 3（高安全性を必要とするアプリケーション）の3つのカテゴリを設け，それぞれについて推奨方式を選定した．
2019年 2月に最終結果がアナウンスされ，Use Case 1ではAsconとACORNが，Use Case 2ではAEGIS-128とOCBが，Use Case 3ではDeoxys-IIとCOLMが選定されている．CAESARに続き，米国商務省標準技術局NISTは2019年2月より次世代軽量認証暗号技術の公募を実施しており[4]，今後4年から5年をかけて米国政府標準方式が選定される予定である．CAESARのUse Case 1に相当する軽量認証暗号を対象としており，これは計算資源の乏しい環境での使用に適した方式であり，IoTデバイスをはじめとした環境で使用されることを想定している．
本研究では，CAESARに応募された認証暗号技術を取り上げ，それらを携帯端末上に実装し，性能評価を実機により行う．IoT時代の到来を見据え，軽量認証暗号技術は安心・安全な情報環境を構築するための有効な解決策であることが期待されている．一方で，計算資源やメモリの乏しいデバイスにおける性能評価は重要な課題であり，実際にこれまでにマイコン上でのCAESAR候補方式の性能評価[5]や軽量ブロック暗号の評価[6]，実装に必要なハードウェアゲート数とった指標[7]において評価が行われてきた．また，ソフトウェア速度を計測するベンチマーク環境eBACS（ECRYPT Benchmarking of Cryptographic Systems）[8]や，ハードウェア性能を評価するプラットフォームATHENa（Automated Tools for Hardware EvaluatioN）[9]が整備されている．
本研究では，CAESARの第3ラウンド候補のうち，軽量アプリケーション向けに提案されている方式を取り上げ，それらを携帯端末上に実装し，その性能を実機により評価する．本研究で考える
方式はCLOC，SILC，JAMBU，Ketje，Ascon，ACORNの6方式であり，携帯端末として5台のAndroid端末を用意する．一般に軽量暗号の要件として，回路規模，消費エネルギー，レイテン
シ，メモリサイズの4点が挙げられる．2点目の消費エネルギーは，省エネの観点から重要であると同時に，限られたバッテリで動作する携帯端末において重要だと考えられることから，本研究ではこれら4つの要件のうち消費エネルギーに焦点を絞る．先に挙げた6方式を5台の端末に実装し，ある一定の長さの入力を処理する．このときに入力1バイト当たりの処理にかかる消費エネルギー（J/Byte）を算出し，これら6方式の比較を行う．測定はバッテリがとりはずせる端末ではハードウェアの計測機器によりバッテリからの電流を計測することで，暗号処理にかかる消費エネルギーを算出する．バッテリがとりはずせない端末ではOSの機能や汎用アプリを利用することとし，ソ－ 62 －

フトウェアによる算出を行う．
2. 対象方式，実装端末，および実験方法
2.1

対象方式

対象方式として，CAESARの第3ラウンド候補方式であり，カテゴリUse Case 1（軽量アプリケーション）向けとして提案されている下記の6方式を考える．
◦CLOC [10]：ブロック暗号に基づく方式であり，証明可能安全性を有する．ブロック暗号の呼び出し回数を削減するよう設計されており，短い入力長に対して効率的に動作する．

◦ SILC [10]：CLOCと同様の設計方針であり，ブロック暗号に基づく方式であるが，よりハードウェアでの実装規模が小さくなるよう条件分岐を少なくしている．ブロック暗号呼び出し回数はCLOCよりも多くなる．
◦JAMBU [11]：ブロック暗号に基づく方式である．CLOC/SILCよりも軽量環境に適したブロック暗号を採用しており，必要メモリサイズの観点からの最適化を行っている．

◦

Ketje [12]：暗号学的置換に基づく設計であり，Sponge構造と呼ばれる設計手法を採用している．メモリサイズが小さくて済み，ハードウェアでの実装に適している．

◦Ascon [13]：Ketjeと同様に暗号学的置換とSponge構造に基づく設計であり，ハードウェアでの小型実装に適している．

◦ ACORN [14]：Use Case 1では唯一，ストリーム暗号に基づく設計であり，内部状態以外の関数が簡素であり，ソフトウェアでの高速実装，ハードウェアでの小型実装に適している．
初期処理はコストがかかる．
CAESARでは設計者がいくつかのパラメータを設定することが許されており，本研究では設計者が第一優先パラメータとしたパラメータを用いて実装を行う．また，CAESARでは設計者がreference実装を提出することが要求されており，これをもとに計測を行う．
2.2

実装端末

本研究ではAndroidをOSとして使用している機種を用いることとし，端末の選定には主に年代とCPUメーカー違いを考慮した．最近の機種としてHuawei P20とZenFone 5z，古い機種としてXperia E dualとGalaxy S III，中間の機種としてZTE Blade L110の計5機種を用いる．それぞれの発売時期，チップセット，CPU，RAM/ROMサイズをまとめる．
◦ Huawei P 20：2018 年 3 月，Hisilicon Kirin 970，4x 2. 36 GHz Cortex-A 73 + 4x 1. 8 GHz
Cortex-A53，4GB/128GB◦

ZenFone 5z：2018年6月，Qualcomm SDM845 Snapdragon 845，4x2.7 GHz Kryo 385 Gold+ 4x1.7 GHz Kryo 385 Silver，6GB/128GB◦ Xperia E dual：2013年1月，Qualcomm MSM7227A Snapdragon S1，1.0 GHz Cortex-A5，512MB/4GB◦

Galaxy S III：2012年6月，Qualcomm MSM8960 Snapdragon S4 Plus，2x1.5 GHz Krait，2GB/32GB◦ ZTE Blade L110：2016年7月，Spreadtrum SC7731G，4x1.3 GHz Cortex-A7，512MB/－ 63 －4GB
以降それぞれ端末1から端末5と呼ぶこととする．
2.3

実験方法

測定対象の各方式は認証暗号技術であり，秘密鍵，付加データ，平文を入力とし，暗号文とタグ2. 実験方法を出力する．秘密鍵は固定長のデータである．付加データは暗号化はせず，認証のみを行うデータ
測定対象の式は認 暗号技術であり，秘密鍵，付加データ 平文を 力とし 暗号文とタグであり，可変長である．これはヘッダとして利用されることを想定している．平文は暗号化も認証
力 る

鍵 固定 のあ付加

暗 化は，を行タも行うデータであり，これも可変長である．出力の暗号文は一般に平文と同じバイト数の可変長
あはる化 認データであり，タグは認証のための固定長データである．バイト当たりの消費エネルギーを計測する際，バイト長の短い付加データ，平文に対しては初期処理にかかる影響が無視できず，バイト長での長い付加データ，平文に対しては初期処理にかかるコストを無視できる漸近的な性能が評価でき際短い
タ 平文に対し は初期 理にかか 影響が無視できず バ ト のると期待される．実際，CAESARでは各提案方式のソフトウェア実行速度を計測するためのベン
長い付 デー
平文に対しては初期処理 かかる ストを無視できる漸近的な性能が評価で ると期待される．実際，CAESAR では各提案方式のソフトウェア実行速度を計測するためのベンチマチマーク環境であるeBACSが利用されており，様々な入力長の速度を計測できる環境が整備されーク環境 ある eBACS が利用されておな入力長の速度を計測できる環境が整備されいている．eBACSにおける暗号化時の付加データ，平文のバイト長（あるいは復号時の付加データ，BACS における暗付加
平文 バイト （あ い 復号時の，暗号 の暗号文のバイト長）
は0バイトから2048バイトまで計9通りの組み合わせを考えている．本研究ではは2えこ

これを参考にし，暗号化時の付加データ，平文のバイト長（あるいは復号時の付加データ，暗号文のバイト長）をZero，Short，Medium，Longの4通りを計測することとした．付加データ，平文，デ

暗号文は同じバイト数であるとし，Zeroは0バイト，Shortは64バイト，Mediumは1536バイトで
文
ト であZ
0S
トi
5 バある．Longは65536バイトの際の計測値と64バイトの計測値との差を算出する．これは，eBACSる ong は6 イ の際の計測値と 6イトの計測値 の差を算出する
れは BACSと同様に，初期処理の影響が無視できることを疑似的に再現するものである．
様に，初期処理の影響が無視で ることを疑似的に再現するものである
認証暗 6 方式
末5台
力サイズ 4 通りそれ れについて暗 化，復号に要するバイト当
認証暗号6方式，端末5台，入力サイズ4通りそれぞれについて暗号化，復号に要するバイト当たりの消ネルギーを 測 る．計 240 通りの組み合 せがれらに加え各端末でスりの消費エネルギーを計測する．計240通りの組み合わせがあり，これらに加えて，各端末でスリ状態をる 各組合 に して 定 数与え消を算

それらリープ状態を計測する．各組合せに対して一定回数の入力を与え消費エネルギーを算出し，それらの平均値を計算する．
計測方法は2通りあり，バッテリが取り外せる端末3,4,5ではトライグル社のモバイル電力測定器で る T YO

1

るは体のる 器で器であるTRYGLE
POWER BENCH[15]を用いる．これは，バッテリと端末本体の間に挿入する
り バ テリかれる電流をリアル計測すールによる測画面の例を図
機器であり，バッテリから
1 示す S LC-E Cは 0 バイト入力時流れる電流をリアルタイム
Iの暗 化 指に計測する．このツールにおり 図 1 はよる測定の画面の例を図1に形

示 す．SILC-ENC- 0 は 0 バ
イト入力時のSILCの暗号化を指しており，図1はこの電換え 電流 示流波形を示している．同時
おりら 差か
暗号化処理に 要に，SILCの実行をスリープ
消費エネルギーを算関数に置き換えた電流を示るしており，これらの差から1,2暗号化処理に必要な消費エ

図1.

 末4によるSILC-ENC-0とSLEEPのベンチマークアプリ実行時の
端
電流波形の例－ 64 －

ネルギーを算出する．
端末1,2ではバッテリの取り外しができず，ソフトウェアによる計測を行う．Android 8.0からはOSで消費エネルギーを観測できるようになっている．また一般に電力測定用にアプリがあり，端末 1 で はAccuBattery [ 16]と い う ア プ リ を 利 用 し， 端 末 2 で はOSの 設 定 か ら 直 接 読 み 取 る．
AccuBatteryではハードウェア，ソフトウェアの区別なく合算されて表示され，アプリの消費電力には画面のバックライトなどの定常的な消費電力が含まれている．このため，暗号化処理を行わなにアプ

[ ]

うアプ

い場合の定常的な消費電力を測定し，暗号処理を実装したアプリとの差を取ることで，暗号処理の利用し 端末 での設接読み取る
ではハア
フトウ ア
消費エネルギーを算出する．OSから直接読み取る場合は，CPUやGPUによる電池消費量を読み取の区別なく合算 れ 表示 れ アプリの消費電力に 画面のバ クライトなどの定常的な消費電力が まれている こ ため，暗号 処理を行わな 場合の定常的な消費電力を測定し，暗号処理ることができ，これを用いる．それぞれ，得られたデータから1バイト当たりの処理に必要な消費を実装したプリとの差エネルギー（J/Byte）を算出する．

3. 実験結果
3.1

実験結果

図2～図6に得られた消費エネルギーのデータを示す．それぞれの図は端末1から5に対応し，各験結果
31
図は縦軸が消費エネルギー（nJ/Byte）
図 2～図 に得消費エネルを対数で示しており，左側に復号時，ギー デー
示す それぞの図は端末 から 5 に対応
右側に暗号化時のデータが示されて
図ラは縦エネーい る． 各 グ
フ軸は 左消か ら入ル
力長e

数 示し

Short，Medium，Longの 順 で 並 ん でお り， 各 入 力 長 に 対 し て 左 か ら
CLOC，SILC，Jambu，Ketje，Ascon，ACORNので 並 ん で い る．
Me i m o 順
g の順で並んでり

図2.

端末1による測定結果

図3.

端末2による測定結果

図4.

端末3による測定結果

入力長0の場合はバイト当たりの消費各入力長に対 て左から CLOC，S C，Jamb ，Ketje sc n，A OR
エネルギーは算出できず，示していない．
3.2

考察

図2～6のいずれのグラフからもブロ ッ ク 暗 号 に基考察 づ くCLOC，SILC，Jambuの消費エネルギーが小さく，そ
図 2～6 の ず のグラフ
もく CLO ，れ に 次 いブロック暗号にでASCONが 続 く．KetjeとSこ
LC れJらm uの グ
消費エー
ACORNはラ フ か ら は，小さ

そで A CO

CLOC，SILC，Jambu，ASCON に
続比べて消費エネルギーが大きい結果となった．
消 費 エ ネ ル ギ ーとの小さたい 順 にCLOC，SILC，Jambu，Ascon
消費 ネルギー 小さい とにCL
SILC，Jambu，Asc n とななっており，KetjeとACORNはShort－ 65 －とMedium/Longで順位が入れ替わる．とi

これはACORNの初期処理のコストがれ替
これは CORN
大 き く， 入理のコストが力長が長くなる
した
くに 入力が長くな にし がってそがってその影響が小さくなるためだ
響が さ な ためだと考えと考えられる．ブロック暗号に基づれる

ロック暗にく果良のく方式の結果が総じて良いのはreference実装の時点である程度の性能が出る実装になっているのに対し

図5.

端末4による測定結果

図6.

端末5による測定結果て，暗号学的置換，ストリーム暗号
る に対してに基づく方式では実行環境に応じた
スト ーム暗号に基づく方式最適化の余地が大きいためだと考えは実行環境に応じた最適化の地が大きいため と考えらられる．より精度の高い比較を行う
より精度の高い比較を うにはには，使用するCPUに特化した最適
る CP に特化 た最実装においての比較が重要であると考えられる．
4. まとめと今後の課題
4 まとめ 今後
本研究では，CAESARの第3ラウンド候補方式のうち，Use（（軽量ア軽量アプリケーション）向け
本研 では CAESAR の第 ラ ンド候補方式のうUs CaseCase 1ケ ション）向けの 6 方式を 象とし，5 台の携帯端末を 意し 実装した．各端末における各方式のイト当たの6方式を対象とし，5台の携帯端末を用意し，実装した各端末における各方式の1バイト当たりりの消費 ネルギー 算出し 6 方式の順位付
行 た
e CORN
ずれも小型ハウの消費エネルギーを算出し，6方式の順位付けを行った．Ketje，ACORNはいずれも小型ハード
ェ 実 に

優れた 能

しる ，本研測定環境 は他 方式

消 エ

ウェア実装においては優れた性能を示しているが，本研究の測定環境では他の方式に比べて消費エネルギーが大きいという結果になった．また，CLOC，SILC，Jambu，Asconはいずれも高い性能を示した．
今後の課題として，reference実装ではなく，実装環境に特化したコードを用いることでより精度の高いができると考えられる
本研究では And
端用したが O
どの他度の高い比較ができると考えられるの OS での比較が望まれる 2

また，本研究ではAndroid端末を使用したが，iOSなどの他
年 2 に公募締め切りを迎えた NIST に
次世代軽量認証暗号技術の公募である 2019年2月に公募締め切りを迎えたNISTghtweighptog aphy プロジェクトでは多数による次世代軽量認証暗号
軽量アプリケーション向けのOSでの比較が望まれる認証暗号方式が提案さ Cryptographyプロジェクトでは多数の軽量アプリケーション向け認ており，それらの比較 重要な課題であると考えられる技術の公募であるLightweight

証暗号方式が提案されており，それらの比較は重要な課題であると考えられる．
謝辞
本研究の推進にあたり，野村太志君（名古屋大学工学部）の多大な協力をいただきました．ここに記して感謝いたします．

参考文献［1］Morris Dworkin. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode(GCM) and GMAC. NIST Special Publication 800-38D, 2007.

－ 66 －［2］Morris Dworkin. Recommendation for Block Cipher Modes of Operation: The CCM Mode forAuthentication and Confidentiality. NIST Special Publication 800-38C, 2004.
［3］Cryptographic competitions, https://competitions.cr.yp.to/caesar.html（2019年5月31日参照）［4］N IST Lightweight Cryptography Project, https://www.nist.gov/programs-projects/
lightweight-cryptography（2019年5月31日参照）［5］松 井充，村上ユミコ．組み込みマイコンRL78での軽量共通鍵暗号のソフトウエア実装評価.
SCIS 2016，3C3-6，2016．
［6］菅原健，鈴木大輔，松井充．Bluetooth Low Energyを題材とした軽量暗号の性能評価．SCIS
2016，2C4-4，2016．
［7］Subhadeep Banik, Andrey Bogdanov, Kazuhiko Minematsu. Low-area hardware implementationsof CLOC, SILC and AES-OTR. HOST 2016: 71-74.
［8］eBACS: ECRYPT Benchmarking of Cryptographic Systems, https://bench.cr.yp.to/（2019年5月31日参照）［9］ATHENa: Automated Tools for Hardware EvaluatioN, https://cryptography.gmu.edu/athena/（2019年5月31日参照）［10］Tetsu Iwata, Kazuhiko Minematsu, Jian Guo, Sumio Morioka, Eita Kobayashi. CLOC andSILC v3. Submission to CAESAR, 2016.
［11］Hongjun Wu, Tao Huang. The JAMBU Lightweight Authentication Encryption Mode (v2.1).
Submission to CAESAR, 2016.
［12］G uido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche, Ronny Van Keer.
CAESAR submission: Ketje v2. Submission to CAESAR, 2016.
［13］Christoph Dobraunig, Maria Eichlseder, Florian Mendel, Martin Schläffer. Ascon v1.2 ,Submission to the CAESAR Competition. Submission to CAESAR, 2016.
［14］Hongjun Wu. ACORN: A Lightweight Authenticated Cipher (v 3). Submission to CAESAR,
2016.
［15］TRYGLE POWER BENCH， ス マ ー ト フ ォ ン 向 け 電 力 測 定 ツ ー ル．http://trygle.com/
product-trygle-power-bench.php（2019年5月31日参照）［16］AccuBattery, https://www.accubatteryapp.com/（2019年5月31日参照）－ 67 －

－ 68 －