DEIM Forum 2019 D1-2

ブロックチェーンとプロキシ再暗号化を用いた共有範囲設定可能な医療情報管理萱原 正彬†
小川

本田 祐一††

泰右††† 松尾山田

達大††

Le Hieu Hanh††

亮輔††† 山崎 友義††† 荒木

串間 宗夫†††

賢二††† 横田治夫††

† 東京工業大学 情報工学科 〒 152–8552 東京都目黒区大岡山 2-12-1†† 東京工業大学 情報理工学院 〒 152–8552 東京都目黒区大岡山 2-12-1††† 宮崎大学 医学部附属病院 病院 IR 部 〒 889–1692 宮崎県宮崎市清武町木原 5200
E-mail: †kayahara@de.cs.titech.ac.jp
あらまし 近年，仮想通貨の基盤技術であるブロックチェーンの医療分野への応用が期待されている．ブロックチェー
ンは分散型 P2P ネットワークで優れたデータ改ざん耐性がある一方，全ユーザが台帳を共有することからプライバ
シーが問題視されている．既存研究においては大規模な電子カルテに対しブロックチェーンの導入を検討しているが，各データの共有範囲を考慮せず単一に暗号化を施している．本研究では医療情報の秘匿性に応じて共有範囲を管理できるプロキシ再暗号化可能なブロックチェーンベースの電子カルテのモデルを提案し，Hyperledger を用いてそのプ
ロトタイピングを行う．
キーワード

ブロックチェーン，プロキシ再暗号化，電子カルテ，Hyperledger
クセスコントロールポリシーをプライベート型のブロックチェー

1 はじめに
1. 1 研 究 背 景
今日，医療現場において電子カルテが広く普及しており医療行為の標準化や業務の効率化，医療データの 2 次利用が進んでいる．電子カルテに記録されるデータは患者の個人情報や健康上重要な情報であることから，誤った医療情報やデータの改ざんを防止するため電子カルテには真正性，見読性，保存性が求められている [1]．
一方近年，仮想通貨の基盤技術であるブロックチェーンの医療分野への応用が期待されている [2]．従来の電子カルテでは医療情報の改ざんによる医療事故の隠蔽などが問題となる [3] が，ブロックチェーンを電子カルテに応用することでこのようなことが事実上不可能となる．しかし，ブロックチェーンは全ユー
ザが台帳を共有することを前提としているためユーザのプライ
バシー保護が課題として挙げられる．また記録するデータが医療情報である場合，この問題はさらに重要視されるため高水準でのプライバシー保護が必要となる．
プライバシー保護には一般的に情報の暗号化が有効である．
しかし，ブロックチェーンのような分散環境下でデータを管理する場合，一般的な公開鍵暗号方式ではデータを複数人で使用する際に鍵を別途共有する必要がある．また医療情報は秘匿性の程度に幅があるため共有範囲を設定できるような暗号技術が好ましいと言える．

1. 2 既 存 研 究
Dubovitskaya らの研究 [4] では，患者の医療情報をクラウド
ストレージに暗号化を施した上で保存し，そのメタデータとアンである Hyperledger を用いて記録するアプローチを提案した．

Dubovitskaya らは複数の医療機関を含めた医療データの 1 次
利用，研究者や解析者を含めた医療データの 2 次利用，保険会
社や薬局といった非医療機関を含めた EHR(Electoric Health

Record) 的利用の 3 つのシナリオにおいてブロックチェーンを
電子カルテに応用した際の真正性や透明性を検証した．また，放射線治療を行なっているガン患者に対してノード数が 4 つの小規模なブロックチェーンネットワークを構築し，患者の医療情報のアップロードや変更，読み取りといったトランザクショ
ンがセキュリティやプライバシーを考慮した上で機能することを実験を通して確認した．

Peng Zhang らの研究 [5] では，医療従事者間での患者の医療情報の受け渡しをブロックチェーンネットワーク上で行う

FHIRChain を提案した．これは OCN(The Oﬃce of the National Coordinator for Health Information Technology) がブ
ロックチェーンベースの医療情報共有に定めている主な 5 つの要件を満たしており，ID 認証に公開鍵暗号方式を用いるなど安全性を高めているものであった．また，リモートでのガン治療をケーススタディに挙げ，D-app と呼ばれる分散型アプリケー
ションを実装した．
しかし，これらの既存研究の共通の問題点としてブロック
チェーンの共有性を踏まえると医療情報の暗号化が非効率であることが挙げられる．Dubovitskaya らの研究 [4] では医療情報の暗号化に共通鍵暗号を使用しているが，ユーザのリボケーションが生じた場合，鍵を再発行した上で再度暗号化を施す必要がある．また，Peng Zhang らの研究 [5] では医療情報の暗号化に公開鍵暗号を使用しているが，複数ユーザに暗号文を送る
場合，各々の公開鍵を用いて個別に暗号化を施す必要がある．

表 1 パブリック型とプライベート型の比較
パブリック型 プライベート型
参加者

制限なし

許可制

情報の秘匿化

不可

可能

ブロックの生成速度遅い

速い

ブロック生成の報酬

必要

不要

ブロックの分岐あり

なし

れる機能が備わっている．これはブロックチェーン上で実行されるプログラムであり以下のような特徴がある．

•

スマートコントラクトに記述されるプログラムは改ざん不可能である．

•

条件処理からデータ操作までの一連の処理続行が可能である．
スマートコントラクトは Ethereum では Contract として，

1. 3 本研究の目的
本研究は，解析者など様々なユーザがアクセスする電子カル

Hyperledger では Chaincode として実装されている．
2. 2 Hyperledger

テにおいて，真正性や保存性を満たしながら効率的に医療情報

Hyperledger [10] は 2015 年 12 月に Linux Fundation によっを暗号化し，患者のプライバシーを保護することを目的とする．

て開始されたオープンソースのブロックチェーンプラットフォー

さらにブロックチェーン開発ツールを用いて上記のシステムをムであり，仮想通貨に限らない広範囲なビジネス用途のブロッ

プロトタイピングすることを目指す．

クチェーン基盤を提供することを目的としたプロジェクトで

1. 4 本稿の構成
本稿は以下の通り構成される．2. 節では本研究の前提となる概念を背景知識として説明する．3. 節では本研究でのブロック
チェーンベースの電子カルテシステムの概要を提案手法としてある．

Hyperledger プロジェクトの 1 つに Hyperledger Fabric [11]と呼ばれるブロックチェーン基盤の実装フレームワークがある．

Hyperledger Fabric の主な特徴として以下が挙げられる．
•

プライベート型の参加方式を採用しており，組織内の述べる．4. 節では 3. 節の手法をプロトタイピングし，その構

ユーザやノードを独自で管理することで信頼度の高いブロック

造や機能の紹介を行う．5. 節では 4. 節で作成したプロトタイ

チェーンネットワークを形成することができる．

プの動作を確認し，暗号化と復号に関する速度評価を行う．最後に 6. 節で本研究のまとめと今後の課題を述べる．

•

ためブロックの正当性を容易に最終確定することができる．

•

2 背景知識本節では背景知識として，ブロックチェーン，Hyperledger，

REST Server，プロキシ再暗号化について紹介する．

軽度で迅速なコンセンサスアルゴリズムを導入している
スマートコントラクトの機能をチェーンコードと呼ばれるプログラムで実現しており，様々な業務処理を記述，実行することが可能である．
また，Hyperledger Fabric を用いたアプリケーションを容易に構築できるよう Hyperledger Composer [12] と呼ばれる開発

2. 1 ブロックチェーン

ツールが用意されている．これはチェーンコードをモデルファブロックチェーンは Satoshi Nakamoto の研究 [6] で発表さイルやスクリプトファイルなどといったファイルから構成された仮想通貨であるビットコインの基盤となる技術のことを指れるビジネスネットワークアーカイブファイルとして記述し，す．その後，ブロックチェーンの改善が研究され様々な分野へ

Hyperledger Composer Playground と呼ばれる Web ベースの応用が行われているため広義的には電子署名とハッシュポイン

ユーザインターフェースを用いてシミュレーションを行うこと

タを使用し改竄検出が容易なデータ構造を持ち，且つ，当該ができるものである．また，ブロックチェーンネットワークにデータをネットワーク上に分散する多数のノードに保持させる

参加するための認証として Card と呼ばれる ID を各ユーザにことで，高可用性及びデータ同一性等を実現する技術と定義さ発行している．

れている [7]．ブロックチェーンは一定数のトランザクションを集約してブロックを作成し，それらをハッシュによって鎖状に繋ぐことからその名がついたと言われている．

2. 3 REST Server
Hyperledger Composer には Hyperledger Composer REST

ブロックチェーンはパブリック型とプライベート型の 2 つにServer と呼ばれる REST API 機能が備わっている．REST

大きく分けられる．それぞれの特徴を表 1 にまとめる．パブリッ

API とは Web システムを外部から利用するためのプログラム

ク型は不特定多数の利用者を想定しており，さらに管理者を用の呼び出し規約の一種であり REST (REpresentational State

意せずにシステムを運用しているため仮想通貨で使用されるこTransfer) と呼ばれる以下の 4 つの設計原則に従って策定されとが多い．一方，プライベート型は独自のネットワークを構成たものである．

し信頼できる利用者のみネットワークの参加を許可しているためビジネスの場面で使用されることが多い．パブリックブロッ•

セッションなどの状態管理を行われず，やり取りされる情報はそれ自体で完結することができる．

クチェーンの代表例としては Bitcoin Core [8] や Ethereum [9]•が，プライベートブロックチェーンの代表例としては後述するている．

Hyperledger が挙げられる．
また一部のブロックチェーンにはスマートコントラクト呼ば情報を操作する命令の体系があらかじめ定義・共有され•全ての情報が汎用的な構文で一意に識別できる．

•

情報の内部に別の情報やその情報の別の状態へのリンク

図 2 提案手法概要

図 1 プロキシ再暗号化を含めることができる．

Hyperledger Composer REST Server を利用することで外部アプリケーションから Hyperledger Fabric のビジネスネッ
トワークに対してトランザクションを実行することができるよ

図 3 従来手法概要

うになる．
（ 6 ） 復号

2. 4 プロキシ再暗号化

cA を skA により以下のように復号する．

プロキシ再暗号化とは暗号文の変換によって復号を委譲する

mg s

方法である．具体例として従来の暗号化方式で A 宛てに暗号化−1skA(g as )=

mg s
(g as )a−1

= m(mod p)

された暗号文を B 宛ての暗号文に変換する場合を考える．この時，A の秘密鍵 skA を B に渡すことはセキュリティ上望まし

BBS 暗号を利用した情報共有管理システムとして児玉氏らのくない．したがって A は自分の秘密鍵 skA を用いて一度暗号研究 [15] が挙げられる．児玉氏らは共有情報に対し，ロジカル

文を復号した後，B の公開鍵 pkB を用いて再度暗号化する必なクラスを単位とした暗号化を行うことでクラス単位でのアク要がある．

セス制御を可能にする手法を提案し，暗号化されたデータベー

プロキシ再暗号化可能な暗号では，A から B への再暗号化
鍵 rkA→B を用いることでプロキシが A 宛ての暗号文を復号することができない状況で B 宛ての暗号文に変換することができ

スとユーザ間にプロキシを配置した情報共有管理システムを作成した．
この手法ではユーザの認証として，ユーザは一意に識別可能な ID を持ち，ID はユーザは高々一つのクラスに対応付けられる．プロキシ再暗号化の流れを図 1 [13] に示す．
プロキシ再暗号化可能な暗号の 1 つに BBS 暗号 [14] がある．

る．また，このクラスは 0 個以上の階層関係を持ったアクセス
レベルに対応付けられる．

BBS 暗号について簡単に述べる．
（ 1 ） セットアップ
安全素数 p = 2q + 1，Z∗p の原始元 g を決め，公開パラメー
タとする．

3 提案手法
本節では既存研究になかった医療情報の秘匿性に応じて公（ 2 ） 鍵生成a ← Z∗2q をランダムに選び，skA = a, pkA = g a (mod p) を

開範囲を管理できるプロキシ再暗号化可能なブロックチェーン
ベースの電子カルテのモデルを説明する．

それぞれ A の秘密鍵，公開鍵とする．

3. 1 提案手法の概要（ 3 ） 再暗号化鍵生成
B
skA , skB を入力として，rkA→B = sk
= ab を A 宛ての暗skA号文から B 宛ての暗号文に変換する再暗号化鍵とする．

本研究で想定するモデルを図 2 に示す．
前章で紹介した児玉氏らの研究のような従来のデータベース（ 4 ） 暗号化を用いたシステムにおいてプロキシ再暗号化を導入すると図 3

平文 m ∈ Z∗2q を pkA で次のように暗号化した暗号文 cA をのようにプロキシサーバを別途用意する必要があった．しかし，提案手法ではプロキシサーバの機能をブロックチェーン内のス

A 宛ての暗号文とする．
scA = (mg s , pkA) = (mg s , g as )(mod p)

マートコントラクトとして記述することで図 2 のようにプロキ
シサーバをブロックチェーンネットワークと一体化することが可能となる．

（ 5 ） 再暗号化

cA と rkA→B を入力として，以下のように cB へと再暗号化

本提案手法はブロックチェーンベースの電子カルテに様々なユーザが自身のアプリケーションを通してアクセスし，医療情を行う．
bs rkA→B
cB = (mg s , (pkA)
) = (mg s , (g as ) a )s= (mg s , g bs )(= (mg s , pkB)) (mod p)

報の追加や取得を行うことを想定している．ユーザの種類として患者と医療従事者の他，医療情報の 2 次利用の際の解析者などが挙げられる．また，電子カルテにアクセスする各ユーザと

図 4 提案手法詳細

図 5 プロトタイピングの概要記録される医療情報はアクセスレベルの情報を保持している．

る．その後，自身の秘密鍵 skC を鍵生成局から取得し復号を試

そのため，医療情報を追加するユーザは情報の秘匿性に応じてみるが，秘密鍵で復号できるように再暗号化されていないため

アクセスレベルを設定することで復号可能なユーザの範囲を指復号は失敗する．

定することが可能になる．

3. 2 医療情報の暗号化と復号
医療情報の暗号化と復号の流れを図 4 に示す．

3. 2. 1 セットアップ

4 プロトタイピング
本節では 3. 節での提案したブロックチェーンベースの電子カ
ルテのプロトタイプを Hyperledger Composer を用いて作成す電子カルテのブロックチェーンネットワークに参加するユー

る．なお，Hyperledger Composer はデータ構造を定義するモ

ザはユーザ登録時に信頼できる第三者の鍵生成局に秘密鍵，公デルファイル (.cto)，トランザクションを定義するスクリプト

開鍵と医療従事者や医療情報解析者といった身分に応じて必要ファイル (.js)，アクセス制御を定義する ACL ファイル (.acl)

な再暗号化鍵の作成を要求する．作成後，ユーザは鍵生成局かなどから成るビジネスネットワークアーカイブファイル (.bna)

ら取得した再暗号化鍵をブロックチェーン上に記録する．

を Hyperledger Fabric のブロックチェーンネットワークにデプ

3. 2. 2 アクセスレベル
電子カルテに記録する医療情報にはアクセスレベルを割り当てている．アクセスレベルはユーザ個人や身分などによって公開範囲を指定する役割を担う．

3. 2. 3 暗 号 化
ユーザ A がデータを電子カルテに記録する際，はじめに自身のアプリケーションにて自らの公開鍵 pkA を鍵生成局から取得し，暗号化を施しておく．暗号化されたデータがブロックチェーンに送られた後，スマートコントラクトはデータのアクセスレベル l を読み取り，ブロックチェーン上から適切な再暗号化鍵 rkA→l を取得する．そして rkA→l を用いて再暗号化されたデータをブロックチェーン上に記録する．
．

3. 2. 4 復号

医師 B がデータを復号する際，スマートコントラクトが復号したいデータに記録されているアクセスレベル l を読み取る．
そして読み取ったアクセスレベルの再暗号化鍵 rkl→B をブロッ
クチェーン から取得し再暗号化を施す．その後，再暗号化されたデータは医師 B のアプリケーションに送られ自らの秘密鍵

skB を鍵生成局から取得し，それを用いて復号を行う．
また，復号が許可されていない解析者 C がデータの復号を試みたとする．スマートコントラクトが復号したいデータに記録されているアクセスレベル l を読み取り，それに適した再暗号化鍵 rkl→C をブロックチェーン上から取得しようとするが，そのような再暗号化鍵は存在しない．その場合再暗号化は行われず，そのまま解析者 C のアプリケーションにデータが送られロイすることでシステムを構築することができる．

4. 1 プロトタイピングの概要
本研究でプロトタイピングしたシステムのモデルを図 5 に示す．
本プロトタイプは Hyperledger Fabric の許可制ブロック
チェーンネットワークを使用しているため，ネットワークの管理者が必要となる．ネットワーク管理者はユーザの登録及び削除を行い，ネットワーク参加者は暗号化された医療情報の閲覧，
医療情報の暗号化および追加，復号および取得を行う．
各ユーザはネットワークの管理者によってブロックチェーン
ネットワークに登録され，同時に鍵生成局が登録されたユーザの秘密鍵，公開鍵および再暗号化鍵を作成しブロックチェーンに記録する．その後，管理者は Hyperledger Composer を通してブロックチェーンネットワークに参加するための Card を登録したユーザに配布し，ユーザ登録が完了する．なお，ユーザの種類は医師，患者，および解析者の 3 者を想定している．
ユーザは Card を使用して自身の Hyperledger Composer

REST Server を立ち上げる．その後ユーザのアプリケーションを使用することで Hyperledger Composer REST Server を通してブロックチェーンネットワークに参加し，システムを利用することが可能となる．アプリケーションは鍵生成局と鍵の受け渡しを行うが，ユーザの秘密鍵および公開鍵が Hyperledger

Composer REST Server に渡されることはない．

表3
再暗号化鍵

保持者

rk P l2

医師，患者

再暗号化鍵
使用状況 対象情報のアクセスレベル
暗号化

l2

rk Me l2

医師，患者

復号

l2

rk P l3

医師，解析者，患者

暗号化

l3

rk Me l3

医師，解析者，患者

復号

l3

表 4 トランザクション

図6
表2

データ構造
アクセスレベル

アクセスレベル共有範囲

l1

暗号化した本人のみが復号可能

l2

医師及び患者のみが復号可能

l3

解析者を含めユーザ全員が復号可能

Transaction

input

output

AddDoctor

personID, name

PersonAddAnalyst

personID, name

PersonAddPatient

personID, name

PersonAddReencKey

personID, reenckey

ReencKey

RemovePerson

personID

AddEncTreatment date, level, description, personID EncTreatment
DecryptTreatment

reenctext, personID

4. 3 トランザクション
スクリプトファイルにはトランザクションが JavaScript に

4. 2 データ構造

よって記述されている．本プロトタイプがブロックチェーン

モデルファイルに記述するデータは大きく Participants とベースの電子カルテとして機能するために作成したトランザク

Assets の 2 種類に分かれ，Participants にはユーザといったションを表 4 にまとめる．それぞれのトランザクションは次セ

Assets を操作する主体の定義が，Assets には医療情報といったクションで説明するアクセスコントロールファイルによって実モノの定義がなされている．また，スクリプトファイルに記述

行可能なユーザが定められている．

•

AddDoctor•

AddAnalyst

いる．なお，図 6 の (*) 印が書かれている要素はそのデータに•AddPatient

おける識別子である．

これらのトランザクションは Participants の Person をそれされるトランザクションの引数についても定義されている．
本モデルのプロトタイプのデータ構造は図 6 のようになって鍵生成局では ID とともにユーザの秘密鍵，公開鍵および再暗号化鍵が保管されている．これらはブロックチェーンと別のサーバに保管されており，ユーザの共有台帳には記録されない．

Participants には Person としてブロックチェーンネットワー
クの参加者が記録されている．識別子に personID を用いてroll には doctor, analyst, patient の 3 種類があり，ユーザ名のname と共に記録されている．
Assets には EncTreatment として暗号化された医療情報がぞれの roll で作成するものである．

•

AddReencKey

このトランザクションは Assets の ReencKey を作成するも
のである．

•

RemovePerson

このトランザクションは指定された PersonID と一致する

Participants の Person と Assets の ReencKey を削除するものである．

記録されている．識別子はアプリケーションから追加した日時•である date を用いており，アクセスレベルの level と暗号化さこのトランザクションは始めにユーザのアプリケーションでれた医療情報である description と共に記録されている．
アクセスレベルは l1, l2, l3 の 3 タイプを用意している．それぞれのデータの共有範囲は表 2 のようになっている．
さらに Assets には ReencKey としてユーザの再暗号化鍵がAddEncTreatment

暗号化した医療情報を入力したアクセスレベルに適した再暗号化鍵で再暗号化し，Assets の EncTreatment として記録するものである．

•

DecryptTreatment

記録されている．識別子は Person と同様の PersonID を用い

このトランザクションは Assets の EncTreatment を復号すており，各ユーザの再暗号化鍵が記録されている．それぞれのる際の再暗号化を施し，そのデータをイベントとしてユーザの再暗号化鍵の役割を表 3 にまとめる．

アプリケーションに発行するものである．イベントとはブロッ

再暗号化鍵はブロックチェーンネットワーク上に保管される

クチェーン上に Assets や Participants としては保存しないもため全ユーザが取得可能であるが，他のユーザ同士やシステムのの，何らかの履歴や外部アプリケーションからの読み取りに管理者との結託が生じない場合，再暗号化鍵のみを取得しても使用したいデータがある場合に利用するものであり，再暗号化

暗号文を復号することはできない．

されたデータが Assets には記録されない．

表6

表 5 アクセスコントロール

実行環境

トランザクション等

操作

DENY/ALLOWCPUIntel Core M 1.3GHz

1 analyst

AddDoctor

ALL

DENY

MemoryDDR3 8GB 1600MHz

2 analyst

AddAnalyst

ALL

DENY

対象者

3

personAddPatient

ALL

DENY

4

personAddReencKey

ALL

DENY

5

personRemovePersonALL6personSystem7

personSystem(History)

OS

macOS Mojave 10.14.2

Dockerversion 18.09.1 , build 4c52b90

Hyperledger Fabricv1.2.1Hyperledger Composer

v0.20.6

DENY

Hyperledger Composer Playgroundv0.20.6

READ

ALLOW

Hyperledger Composer REST Server

v0.20.6

ALL

ALLOW

記入した医療情報を暗号化し，Hyperledger Composer REST

4. 4 アクセスコントロール
アクセスコントロールファイルには各ユーザや役割によってトランザクションの実行範囲が設定されている．本プロトタイ

Server に暗号化されたデータと選択したレベル，アプリケー
ション内で取得した日時，および自身の personID を引数とした AddEncTreatment を POST する api を実行する．

プで設定したアクセスコントロールとその内容を表 5 にまとめ•る．なお，ここでの対象者にシステム管理者は含まれていない．

この機能はブロックチェーン上に記録されている EncTreat-

4. 5 管理者用アプリケーション

医療情報の復号および取得

ment の識別子である date をフォームに入力し復号ボタン
をクリックすることで Hyperledger Composer REST Server

本プロトタイプの管理者用アプリケーションは Node.js にに入力した日時と自身の personID を引数とした Decrypt-

よって記述されており，実行するとローカルホストのポート番

Treatment を POST する api を実行する．さらに実行した号 4100 番を開く．管理者用アプリケーションは以下の機能をDecryptTreatment の transactionId を引数とし Hyperledger

持つ．

Composer REST Server に historian を GET する api を実行

•

医師の登録

する．取得した historian には DecryptTreatment を実行した

この機能は personID と name をフォームに入力し送信する際に発行された event が履歴として残っているため，そこからことで Hyperledger Composer REST Server に入力したデー

再暗号化された医療情報を読み取り鍵生成局に自身の秘密鍵

タを引数とした AddDoctor と AddReencKey を POST するを要求し，取得した秘密鍵を使用することで医療情報の復号を

api を実行する．

行う．

•

解析者の登録この機能は personID と name をフォームに入力し送信する

4. 7 鍵 生 成 局

ことで Hyperledger Composer REST Server に入力したデー

本プロトタイプの鍵生成局はアプリケーションと同様，Node.js

タを引数とした AddAnalyst と AddReencKey を POST するによって記述されており実行するとローカルホストのポート番

api を実行する．

号 3000 番を開く．鍵生成局には各ユーザの鍵情報が保管され

•

患者の登録

この機能は personID をフォームに入力し送信ボタンをクリッ
クすることで Hyperledger Composer REST Server に入力したデータを引数とした AddPatient と AddReencKey を POSTている他，再暗号化鍵を生成するためのプロキシの秘密鍵も保持しているため，常に信頼された第三者であることが前提条件となる．

4. 8 Hyperledger Composer REST Server

する api を実行する．
本プロトタイプで使用する Hyperledger Composer REST

4. 6 ユーザ用アプリケーション

Server は立ち上げる際にユーザのカードが必要となる．デフォ

本プロトタイプのユーザ用アプリケーションは管理者用同

ルトではローカルホストのポート番号 3000 番を開くよう設定

様，Node.js によって記述されており実行すると医師用，解析されているため鍵生成局と重複しないようにポート番号を指定

者用，患者用でそれぞれローカルホストのポート番号 5100 番，

する必要がある．

6100 番，7100 番を開く．また，それぞれのユーザ用アプリケー
ションには自身の personID が記録されている．ユーザ用アプ
リケーションは以下の機能を持つ．

•

暗号化された医療情報の閲覧

この機能は Hyperledger Composer REST Server に Assetsの EncTreatment を GET する api を実行する．

•

医療情報の暗号化および追加

5 実験

これまでに本研究の提案手法をプロトタイピングしたシステ
ムを説明した．本節では暗号化および復号の速度に関する評価
実験を行う．本実験の実行環境を表 6 に示す．なお実験に際し動作確認を行ったところ，アクセスレベルに応じて暗号化および復号が適切に行われていることが確認できた．

この機能は level を l1，l2，l3 から選択し詳細欄に暗号化した
い医療情報を記入し追加ボタンをクリックすると始めに鍵生成
局に自身の公開鍵を要求する．そして取得した公開鍵を用いて

5. 1 実 験 目 的
暗号化と復号にかかる所要時間を各フェーズごと記録すると

ともに、暗号化を施す情報のデータ量の大きさによってどのよ
うに所要時間が変化するかを記録することで暗号化および復号のオーバーヘッドを確認する．

5. 2 実 験 内 容
公開パラメータの安全素数 p = 902723 を用いた際の文字数
図 8 暗号化：再暗号化

図 7 暗号化：暗号化

が 1,10,50,100,200,300 字のアルファベットで書かれたテキス
トデータに対し暗号化 ，復号にかかったそれぞれのフェーズの所要時間を計測する．なおフェーズは暗号化，復号に対し以下の 4 フェーズを考える．

•

暗号化 ：アプリケーションでの暗号化，再暗号化，Hy-

perledger における処理，合計•

復号 ：再暗号化，アプリケーションでの復号，Hyper-

ledger における処理，合計

図9

暗号化：Hyperledger 処理

図 10

図 11

復号：再暗号化

図 12 復号：復号

復号：Hyperledger 処理

図 14 復号：合計

暗号化：合計それぞれの文字数のテキストデータに対し実験を 5 回繰り返し平均所要時間と本実験における 95%信頼区間を記録した．

5. 3 実 験 結 果
暗号化の際の暗号化，再暗号化，Hyperledger における処理，合計の所要時間をそれぞれ図 7，図 8，図 9，図 10，復号の際の再暗号化，復号，Hyperledger における処理，合計の所要時
間をそれぞれ図 11，図 12，図 13，図 14 に示す．

5. 4 考察以上の結果を受けて考察を行う．
まず，図 7，図 8，図 9 から暗号化の際の所要時間について
はアプリケーションでの暗号化と再暗号化が Hyperledger における処理に比べ極めて短く，文字数が増えるにつれ比例的に

図 13

時間が増加することが分かる．実験で扱った文字数程度ではHyperledger における処理が合計の大部分を占めるため，図 9，

表 7 暗号化の際の各フェーズの所要時間の割合

図 10 から分かるように Hyperledger における処理と合計の所
要時間のグラフはほぼ一致しており，暗号化におけるオーバー
ヘッドの問題は表 7 からも無視できると言える．
次に復号の際の所要時間については図 11，図 13 から再暗号

文字数

1

10

50

100

200

300

暗号化 (%)

0.00150.00690.0217

0.05650.11970.1251

再暗号化 (%)

0.01540.02930.06130.19450.29480.3811Hyperledger(%) 99.9831 99.9638 99.9170 99.7491 99.5855 99.4939

化と Hyperledger における処理が暗号化の際と同様な時間で推移していると分かる．これは暗号化と復号でのこれらの処理の違いがほとんどないためと考えられる．また，図 12 からアプ

画などの大容量データについてはシーケンス解析において暗号

リケーションでの復号の所要時間は文字数が増えるにつれ比例化を必要としないため，今回は暗号化の対象外となっている．

的に増加するが，増加率が他の処理に比べ大きいことが読み取

また，参考にした医療情報は個人情報保護の観点から患者を一れる．これはアプリケーションでの復号の際に極めて大きな素意に特定できるような情報を含まず，ある患者に対して行った数のモジュラ逆数を算出する際の計算量の多さによるものと考

医療指示を抽出する際は連結不可能な匿名化 ID を用いており，えられる．また，復号におけるオーバーヘッドの問題は暗号化

宮崎大学の倫理審査委員会及び東京工業大学の人を対象とするを施す情報が本プロトタイプのような電子カルテに記録する医研究倫理審査委員会の承認を得ている．

療情報の場合おおよそ 300 字程度と考えられ，表 8 や図 15 の本実験でのブロックチェーンネットワークが小規模なものでグラフからも読み取れる通り，300 字程度では Hyperledger にあり，ネットワークの規模が実用化を想定した程度に拡大する

おける処理での所要時間と同程度である．

と Hyperledger における処理時間が増加すると予想される．さ実際の医療現場において電子カルテに記録されるデータ量はらに，本実験で使用した BBS 暗号は復号に時間を有する暗号宮崎大学医学部附属病院で使用されている電子カルテシステム

方式であり，他のプロキシ再暗号化可能な暗号方式を使用する

WATATSUMI [16] に記録された医療情報を参考にすると 250ことでアプリケーションでの復号時間を短縮することが期待で字程度である．これは患者の基本情報と医療従事者が記録する

きる．以上から，アプリケーションでの復号におけるオーバー

医療指示情報を合算した文字数となっている．なお，画像や動ヘッドも問題も許容できる範囲であると考えられる．

表8

復号の際の各フェーズの所要時間の割合

直接ブロックチェーン上に保存した場合は復号に相当な所要時間がかかってしまうと予想される．しかし，オフチェーン上に

文字数

1

10

50

100

200

300

再暗号化 (%)

0.00690.0136

0.06420.10110.13810.1833

復号 (%)

0.49173.215514.1322 24.8865 39.8926 49.9193

保管されたデータの耐消去性などといった課題点が残っており今後の研究の対象としていくべきである．

Hyperledger(%) 99.5014 96.7709 85.8036 75.0124 59.9693 49.8974

謝辞本研究の一部は，厚生労働行政推進調査補助金政策科学推進研究事業「ナショナルデータベース (NDB) データ分析における病名決定ロジック作成のための研究」の助成により行われた．また，本研究は宮崎大学医学部附属病院との共同研究であり，宮崎大学の倫理審査委員会及び東京工業大学の人を対象とする研究倫理審査委員会の承認を得ている．関係者の協力に感謝する．
文

図 15 復号の際の各フェーズの所要時間の割合

6 おわりに
6. 1 ま と め
本研究では患者や医療従事者，解析者といった様々なユー
ザが自身のアプリケーションを通してアクセスするブロック
チェーンベースの電子カルテにおいて，医療情報を単一に暗号化するのではなくプロキシ再暗号化とアクセスレベルを用いて暗号化し，スマートコントラクトに記述されたプロキシ機能によって医療情報の公開範囲を設定できるモデルを提案した．
また，Hyperledger Composer を用いて提案手法のプロトタ
イピングを行い暗号化や復号が正しく行われることを確認するとともに，暗号化の速度評価の実験を行うことで暗号化や復号にかかるオーバーヘッドが使用状況を想定した際に許容できる範囲であることを示した．

6. 2 今後の課題
まず，実用に向けてより精密にセキュリティ評価を行う必要がある．特に，本研究で用いたプロキシ再暗号化は BBS 暗号方式であり一般的には耐結託性が無いと言われている．耐結託性を持った暗号方式 [17] を使用することや，本研究ではプロキ
シサーバの役割をスマートコントラクトに内包しているため耐結託性についての議論をすることは意義が大きい．
また，本研究では暗号化した医療情報をブロックチェーン上に直接記録している．一般的には医療情報をブロックチェーン
を用いて保管する際はブロックチェーン上には医療情報のポイ
ンタやハッシュをかけたものを記録し，本来の医療情報はオフ
チェーン上に保管することが主流となっている．これは医療情報には画像データといった容量の大きなものも含まれることか
らスケーラビリティを考慮しているものと考えられている．実際に，MRI で撮影した画像データのような数 MB のデータを

献[1] 厚生労働省. 医療情報システムの安全管理に関するガイドライ
ン. Vol. 3, , 2005.
[2] Matthias Mettler. Blockchain technology in healthcare: Therevolution starts here. In the proceeding of the 18th IEEE
International Conference on e-Health Networking, Applications and Services (Healthcom), pp. 1–3, 2016.
[3] 長島光一. 電子カルテの法的課題と民事訴訟における取扱. 法律
論叢第 90 巻第 4・5 合併号, 2018.
[4] Alevtina Dubovitskaya, Zhigang Xu, Samuel Ryu, Michael
Schumacher, and Fusheng Wang. Secure and trustable electronic medical records sharing using blockchain. In AMIA
Annual Symposium Proceedings, Vol. 2017, p. 650. American Medical Informatics Association, 2017.
[5] Peng Zhang, Jules White, Douglas C Schmidt, Gunther Lenz, and S Trent Rosenbloom. Fhirchain: applying blockchain to securely and scalably share clinicaldata. Computational and structural biotechnology journal,
Vol. 16, pp. 267–278, 2018.
[6] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash
system. 2008.
[7] 日本ブロックチェーン協会. http://jba-web.jp/.
[8] Bitcoin core. https://bitcoincore.org/ja.
[9] Ethereum. https://www.ethereum.org.
[10] Hyperledger. https://www.hyperledger.org.
[11] Christian Cachin.
Architecture of the hyperledger
blockchain fabric. In the proceeding of the Workshop on
Distributed Cryptocurrencies and Consensus Ledgers, Vol.
310, 2016.
[12] Hyperledger composer. https://hyperledger.github.io/
composer/latest.
[13] 光成滋生. クラウドを支えるこれからの暗号技術. 秀和システム,
2015.
[14] Matt Blaze, Gerrit Bleumer, and Martin Strauss. Divertible
protocols and atomic proxy cryptography. In the proceedingof the International Conference on the Theory and Applications of Cryptographic Techniques, pp. 127–144. Springer,
1998.
[15] 児玉快, 横田治夫. データやユーザの効率的な追加・削除が可能
な秘匿情報アクセス手法. 第 7 回データ工学と情報マネジメン
トに関するフォーラム, 2015.
[16] 電 子 カ ル テ シ ス テ ム WATATSUMI.
https://www.
corecreate.com/02_01_izanami.html.
[17] 平田拓三, 宮沢駿輔, Hieu Hanh Le, 横田治夫. プロキシ再暗号化と検索タグを用いた範囲クエリ可能な秘匿情報の耐結託共有
手法. 第 10 回データ工学と情報マネジメントに関するフォーラ
ム, 2018.