スマートフォンにおける準同型暗号を用いた暗号化手法の比較
理学専攻・情報科学コース

松本茉倫

はじめに

1

IoT デバイスで取得したセンサデータの中には，秘匿性が高いデータが存在しており，安全とは言えないク
ラウドサーバ上では情報漏洩に備え，個人情報を保護する必要がある．そこで，暗号文同士の加算・乗算が任意回数可能な Leveled 準同型暗号 (以下 LHE: Leveled
Homomorphic Encryption) が注目されている． LHEによって，IoT デバイスで個人情報を暗号化しクラウドサーバで暗号化したまま分析，データ分析者が分析結果を復号することが可能になる．しかし，LHE による暗号化は時間がかかり，暗号文サイズが大きいため通信量が多くなってしまうことが計算能力の低い IoTデバイス上での実装の課題となっている． IoT デバイ
スの中でも，スマートフォンは近年ユーザにとって極めて使用頻度が高い重要なデバイスであり，ユーザのプライベートな情報を含んだ非常に多くのデータを取得している． 本研究では，スマートフォンで取得したデータのクラウドサーバを使ったデータ活用を想定してシステムデザインを既存手法と提案手法で 3 つ実装し，IoT デバイスへの負荷・クラウドサーバへの負荷・通信量の 3 つの指標で比較した．その結果，提案手法はスマートフォンにおいて最大で約 2670 倍高速に暗号化可能であることを示した．

IoTデバイス(IoT)(1) 鍵生成公開鍵(2) 暗号化
暗号文(LHEへ変換)(3) 統計分析
分析結果(4) 復号
分析者

図 1: IoT デバイス (IoT)・クラウドサーバ (CS)・復号サーバ (DS) の役割

2.3

1. DS が LHE で暗号化した AHE の秘密鍵は CS に，AHE の公開鍵を IoT に配布．
2. IoT が AHE で平文を暗号化．
3. CS が AHE 暗号文を LHE 暗号文へ変換し，LHE暗号文を分析．
4. DS が分析結果を復号．

デザイン 1 (Baseline)

Baseline として，シンプルに LHE で平文を暗号化するデザイン 1 は以下の処理を行う．
1. DS が LHE の公開鍵を IoT デバイスとクラウドサーバに配布．
2. IoT が LHE で平文を暗号化．
3. CS が LHE 暗号文を分析．
4. DS が分析結果を復号．
2.2

デザイン 2 (既存手法)

既存手法のデザイン 2 の処理を以下に示す．この手法は，Lauter ら [1] によって提案され，Gentry ら [2]によって実装手法が提案された．AES 鍵のみを LHEで暗号化することによって，高負荷な LHE を多く使わなくて済む．

1. DS が LHE の公開鍵を IoT と CS に配布．
2. IoT が AES で平文を暗号化し，LHE で AES 鍵を暗号化．
3. CS が AES 暗号文を LHE 暗号文へ変換して，LHE暗号文を分析．
4. DS が分析結果を復号．

デザイン 3 (提案手法)

提案手法のデザイン 3 は IoT デバイスが LHE より軽量な RLWE 問題ベースの加法準同型暗号 (以下 AHE:Additive Homomorphic Encryption) で平文を暗号化し，代わりにクラウドサーバが LHE 暗号文へ変換する手法である．LHE 暗号文への変換は，LHE で暗号化された AHE の秘密鍵と AHE 暗号文との加算・乗算によって可能となる．以下に処理を示す．

図 1 は，システムを構成する IoT デバイス (IoT)・クラウドサーバ (CS)・復号サーバ (DS) の役割を示している．本研究では 3 つのシステムデザインを比較する．

2.1

復号サーバ(DS)

公開鍵

システムデザイン

2

クラウドサーバ(CS)

3

実験

3.1

実験概要

3 つのデザインで 256B の平文を LHE で暗号化する場合を想定する．表 1 のように，IoT デバイスにはス
マートフォンの Google Pixel 3 に加えて，低性能なデバイスである Raspberry Pi を使用した．IoT デバイスへの負荷 (IoT デバイスの実行時間，CPU 使用率，メモリ使用量)・クラウドサーバへの負荷 (クラウドサー
バで LHE 暗号文へ変換する場合の実行時間，変換処理の CPU 使用率，メモリ使用量)・通信量 (IoT デバ
イス–クラウドサーバ間，復号サーバ–IoT デバイス間
で IoT デバイスが送受信するファイルサイズ) という 3つの指標で比較を行った．表 2 のパラメータについて，クラウドサーバが LHE 暗号文への変換処理後，Levelは 4 程度残るように選択し，同程度のセキュリティレベルになるように設定した．Level とは暗号文同士の演算可能回数を制御するパラメータで，「Level が 4 程度残る」とは，3 回程度の準同型乗算は可能であることを指す．デザイン 2(既存手法) では AES から LHEへの変換処理で準同型乗算の回数が他 2 つのデザインよりも多いため Level は高く設定されている．

Design 1

Design 2

Design 3

Design 1

Design 2

Design 3

Design 1

Design 2

Design 1

Design 3

Design 2

Design 31250

1006001500

100020050251000

Time [s]Time [s]400

Memory usage [MiB]

CPU usage [%]75500

75050025000

Google Pixel 3

Raspberry Pi

Design 2

Raspberry Pi

Google Pixel 3(b) IoT の CPU 使用率(a) IoT の実行時間
Design 10

Google Pixel 3

Design 1

Design 3

Design 2

Raspberry Pi0(c) IoT のメモリ使用量
Design 1

Design 3

Design 2(d) CS の実行時間

Design 3

Design 1

Design 3250050254000300
02000100000(e) CS の CPU 使用率(f) CS のメモリ使用量

1500

Receive file size [MiB]

Memory usage [MiB]75

Send file size [MiB]5000

CPU usage [%]Design 2

200010010005002000

1500

1000

50000(g) 通信量 (IoT–CS 間)(h) 通信量 (DS–IoT 間)

図 2: 256B の平文を LHE 暗号文化する場合の実験結果．デザイン 1 は Baseline，デザイン 2 は既存手法，デザイン 3 が提案手法である．(a)IoT デバイスの実行時間は平文の暗号化時間，(b) と (c) はその暗号化処理の CPU使用率とメモリ使用量である．(d) クラウドサーバの実行時間は LHE の暗号文へ変換する場合の実行時間で，(e)と (f) はその変換処理の CPU 使用率とメモリ使用量を指す．(g) の通信量は IoT デバイスがクラウドサーバに送る暗号文のファイルサイズ，(h) は復号サーバが IoT デバイスに配布する公開鍵のファイルサイズを指す．
実験結果

3.2

図 2(a)(b)(c) より，デザイン 3(提案手法) は IoT デバイスへの負荷に関して最も有利であることが分かる．
Raspberry Pi ではメモリ不足のためデザイン 2(既存手法) は実行不可能であった．この理由は，図 2(h) のDS-IoT 間の通信量，すなわち IoT デバイスが使う暗号化鍵のサイズが既存手法では約 2.3GiB と特に大きいためだと考えられる．既存手法では LHE パラメー
タの Level が大きいため鍵が大きくなる．提案手法は，
図 2(g)・2(h) の通信量に関しても最も優れている．一方で，図 2(d)(e)(f) のように LHE への変換処理には課題が残っていることが分かった．

4

表 1: 実験環境
OSGoogle Pixel 3(IoT デバイス)

謝辞
本研究は一部，JST CREST JPMJCR1503 の支援を受けたものである．

ARM Cortex-A75(2.5 GHz) 4Cores

Main Memory

ARM Cortex-A55(1.6 GHz) 4Cores
4GBOS

Raspbian GNU/Linux 10.0

CPU

ARM Cortex-A53(1.4 GHz) 4Cores

Main Memory

1GBOS

CentOS 6.10

Raspberry Pi 3
Model B+(IoT デバイス)

クラウドサーバCPU
Main Memory

まとめと今後の課題

IoT デバイスの LHE 暗号化の負荷を削減するため，
IoT デバイス側では LHE よりも軽量な AHE によって平文を暗号化し，代わりにクラウドサーバ側で AHE から LHE の暗号文へ変換する手法を提案した．実験の結果，既存手法に比べて，提案手法では IoT デバイスへの負荷を格段に減らすことが可能であり，Raspberry
Pi のようなメモリの限られたデバイスでも実行可能であることを示した．よって，提案手法の方が優れたシステムデザインであると考えられる．
今後の課題として，クラウドサーバにおける変換処理の高速化が挙げられる．

Android 9.0

CPUIntel®Xeon®Processor E5-2643
v3 (3.4GHz) 6Cores × 2 Sockets
512GB

表 2: パラメータ
デザイン 1LHE

Level: 7, Security:130 bit

デザイン 2

LHE

Level: 45, Security: 131 bit

AES

Key length: 128 bit

LHE

Level: 8, Security: 130 bit

AHE

Degree of a polynomial: 128, Security: 128 bit

デザイン 3

参考文献[1] Kristin Lauter, Michael Naehrig, and Vinod Vaikuntanathan. Can homomorphic encryption be practical? InCCSW ’11: Proceedings of the 3rd ACM workshop on
Cloud computing security workshop, pp. 113–124, 2011.
[2] Craig Gentry, Shai Halevi, and Nigel P. Smart. Homomorphic evaluation of the aes circuit. In Advances in Cryptology – CRYPTO 2012, pp. 850–867, 2012.