初めに
Blockchainを含むDistributed Ledger Technology (DLT)は、cryptocurrency (暗号資産)を実現する際に、用いられた技術です。特に、Bitcoinでは、記録物(block)の順序(時刻)が、改ざん困難になるようにする目的で、blockchainを利用しています。ここで、記録する対象は、物事が実行されたことを示す記録(log, history, ledger)を対象としています。Bitcoinでは、blockを記録する際に、誰か特定の者(認証局、Time Stamping Authority)が、時刻を決める方式ではなく、不特定多数の者が順序を確定させることができるように、blockchainを用いています。順序を決める方法は、前のblockと記録するblockの間の関係(blockのhash値とblockのhash値の関係)が、ある値(上位のbitからあるbitまでが0)になる値を見つけた者が、順序を決め、blockを記録する方法です。よく知られているように、この順序決めの計算(hash値の探索)が、miningと呼ばれている計算です。このhash計算は、計算機で多大に繰り返し、値を探索するため、多くの電力量を必要とし、地球環境温暖化原因の１つになりえるため、一般的に問題となっています。本来、記録順序を決める者が、信頼できるならば、この計算は必要のない計算です。
次に、BlockchainやDLTを利用することで、一般的に実現されている機能について説明します。そして、今回、紹介するImmutable Storageが、BlockchainやDLTで得られる機能をより簡単に得られることを説明し、最後に、使用例とともにImmutable Storageの使用方法の1つについて紹介します。
Blockchain関連技術で実現可能な機能
BlockchainやDLTを利用することで、一般的に実現されている機能について説明します。
記録時刻証明と記録順序証明
Bitcoinが用いたように、前のblock(記録物)と次に記録するblockとの関係性を持たせるblockchain構造は、時系列での記録物の存在証明に使用することができます。以下に、主に知られている記録時刻証明方法や記録順序証明方法を纏めます。
| # | 方法 | 利用技術 | 説明 |
|---|---|---|---|
| 1 | Self-signed Time Stamp | Digital Signature |
|
| 2 | Blockchain | Hash |
|
| 2.1 | Bitcoin | Hash, (Blockchain) |
|
| 2.2 | KSI (Keyless Signature Infrastructure) | Hash, (Blockchain) |
|
| 2.3 | Hyperledger Fabric | Digital Signature, Hash, (Blockchain) |
|
| 3 | Digital Time Stamp Certificate | Digital signature |
|
| 3.1 | Qualified Eelectronic Time Stamp | Digital signature, (Digital Time Stamp Certificate) |
|
改ざん耐性(原本保証性)・記録者証明性(存在証明性)
時刻や順序の改ざん耐性には、hashをchainで関連付けるblockchainが改ざん耐性を向上させる方法として有効です。しかしながら、記録物そのものの改ざん耐性や記録者の証明性を高める方法は、blockchainではなく、electronic signature (電子署名)が、一般的に使用されています。以下の表に、記録者証明性が高くなる順に、各種署名方法を纏めます。
| # | 署名方法 | 説明 |
|---|---|---|
| 1 | Electronic Signaure |
|
| 2 | Digital Signature |
|
| 3 | Advanced Electronic Signature |
|
| 4 | Qualified Electronic Signature |
|
記録物削除耐性
前記のように、記録物の改ざん耐性は、記録物に署名することで得られ、更に、それら記録物のhash値を前後に関連付けたblockchain構造により、記録順序方向にも改ざん耐性を確保できます。ただし、すべての記録が消された場合や記録装置の故障により消えてしまった場合には、記録は残りません。blockchain構造による記録物(block: log, history(履歴), ledger(帳簿))が、ある特定の場所(装置)で取り消された時に備えて、複数個所に同じ内容を複製し、同じ内容を分散させて記録することで、記録物削除耐性を向上させる方法は、Distributed Ledger Technology (DLT)と呼ばれています。Bitcoinのように、記録物の保管場所が信頼できないことを前提としている場合には、記録物を分散させ、記録することが有効です。また、分散して複製された記録物は、複数の装置に分散して、参照可能です。しかしながら、参照の分散を除いて、保存場所がある程度信頼できる場所ならば、本来、多くの複製を必要としません。 例えば、Hyperledger Fabricでは、記録物の保存場所が特定可能なように、保存装置の署名を追加し、記録しています。この記録装置の信頼性(信頼できる組織に運営されている装置で、耐故障性のある装置(冗長化された記録装置等))が、あれば、１か所に保存されていても、記録物削除耐性は、十分である場合もあります。
実行証明性
あることを実行したことを確認・証明する際に、実行したことを記録するlogが、一般的に利用されています。通常記録するlogに署名を付けるとことで、実行者の実行意思が、記録に残り、記録後に意思を証明可能となります。同様に、この記録(block: log, history, ledger)をblockchain構造に保存することで、上記の記録時刻(または順序)証明性、改ざん耐性(原本保証性)、記録者証明性(存在証明性)が得られます。更に、記録を複数個所に複製し記録するDLTを使用することで、記録物の削除耐性が得られます。
Ethereumのsmart contractやHyperledger Fabricのchain codeなどの(加工)プログラムは、複数の計算機で、同一の処理を実行し、複数計算機で、結果が同じであることを記録することで、プログラムが実行した内容の証明性を向上させようとした試みであると考えます。しかしながら、これらの加工プログラム(smart contractやchaincode)は、記録を依頼するプログラムと記録装置の間にある記録物加工プログラムであり、特に、実行証明性を向上させることはないと考えます。なぜならば、加工プログラムは、入力された情報(署名付きの情報)をそのまま、記録装置に記録した場合と、入力された情報を加工して記録装置に記録した場合では、実行証明性の程度は変わらないと考えるからです。例えば、1+2=3をしたことを証明する方法は、次の２通りが考えられます。(どちらの場合にも、実行証明には記録者(実行者)の署名を用います。)
- 1と2を入力したことを署名付きで記録、実行結果3も署名付きで記録要求、演算"+"は加工プログラムが実行
- 入力(1と2), 演算方法(+)、結果(3)を署名付きで記録、加工プログラムは入力に加工しないで記録装置に記録
一般的に、$f$($\vec{x}$)=$\vec{y}$ (入力$\vec{x}$, 演算$f$, 出力$\vec{y}$)をしたことの記録証明は、入力$\vec{x}$と出力$\vec{y}$に署名し、演算$f$は、加工プログラムで実行する証明方法と、入力$\vec{x}$と演算$f$と出力$\vec{y}$の全てに署名し記録する証明方法と、同一です。どちらの場合にも記録者の署名により、実行したと(入力と出力に間違いがないこと)を証明しているからです。
よって、演算$f$は、加工プログラムで実行しても、記録要求を発行するプログラムにあっても、実行証明性の効果は、同一です。以上の理由により、演算$f$の実行は、冗長な演算を複数の計算機で実行して、電力消費を増加させる"加工プログラム"よりも、１つの計算機で実行する”記録要求を発行するプログラム"上にある方が、好ましいと考えます。すなわち、加工プログラムは、できる限り何もしないことが望ましいと考えます。
Blockchain, Distributed Ledger Technology
以上の記録時刻(順序)証明、改ざん耐性(原本保証性)・記録者証明性(存在証明性)、記録物削除耐性、実行証明性は、hashやdigital signatureの技術により実現されていることを説明しました。本来、記録物blockの前後関係をchainで関連付けるblockchain構造は、記録順序を関連付けるために用いられている記録構造です。しかし、ここでは、blockchainは、便利上、上記で説明した改ざん耐性等も含めた性質・機能を実現する技術の総称として、呼ぶこととします。
Immutable Storage
上記のように、記録物(log, history, ledgerの記録)に、記録時刻証明や改ざん耐性などを機能は、Blockchainにより実現できます。ある機能を実現する際に、追加として、log, history, ledgerの記録が行われることが、ほとんどの場合だと思います。よって、これらのlog, history, ledgerの記録は、容易に実現できることが、好ましいと考えます。しかしながら、Blockchain機能を提供する部品として、一般的に使用されているHyperledger FabricやEthereum系の部品類は、容易にlog, history, ledgerを記録するための部品であるとは、言い難いと考えます。そこで、Immutable Storageでは、Hyperledger Fabricをlog, history, ledgerをblockchainで記録する部品として、容易に使用できる形とした上で、以下のような多種な機能を、提供しています。(Hyperledger Fabricを使用しないで、もっと軽量な独自blockchainを作成する方が、良いかもしれませんが、open sourceとして、Hyperledger Fabricは公開してくださっているため、部品として使用させていただいています。)
| # | 機能 | 説明 |
|---|---|---|
| 1 | 改ざん耐性(原本性保証) | 記録者、保存装置、記録順序調整プログラムの署名(複数署名)と内容物のchecksum (sha256)により実現 (主にHyperledger Fabricの機能による) |
| 2 | 記録者(意思)証明性 | 証明書と記録者しか持っていない秘密鍵による署名により実現 |
| 3 | 記録時刻・順序証明性 | 記録者が記録したとしているtimestampへの署名、記録順調整プログラムの署名により実現 (信頼される署名により電力消費に配慮) |
| 4 | 記録物削除耐性 | 記録装置の信頼性と装置提供組織の信頼性、DLT機能による複数装置への複製(DLT機能はHyperledger Fabricによる) |
| 5 | 実行証明性 | 記録者の署名により実現 (記録加工プログラムは最低限にすることで、電力消費に配慮) |
| 6 | 他プログラムとの連携 | 次の形態用の部品を提供しています。これにより容易にlog, history(履歴), ledger(帳簿)を記録参照可能です。
|
| 7 | 記録者管理機能 | Web browserによる記録者用秘密鍵(署名用)・証明書管理機能(作成、保存など)、記録者権限無効化(削除など) |
| 7.1 | 記録者連携 | LDAPで管理された記録者との連携、JPKI card (マイナンバーカカード)との連携機能 |
| 8 | 機密性 | 署名・証明書を使った記録物への認可、暗号化による記録物の機密性保持 |
| 9 | 匿名性 | 証明書に記載する内容の工夫により実現(CommonName記載内容の乱数生成等) |
| 10 | 認証機能 | 記録者の署名と証明書による認証 (client認証機能)、鍵生成はEC 512bitを使用 |
| 11 | 記録媒体選択機能 | 設定により記録媒体(K8s persistent volume)を選択可能 |
| 12 | 簡易記録物複製 | Web browserを使用して記録内容を記録媒体から複製する機能 |
| 13 | その他 | より使用可能性を高めるための機能拡張中 |
Immutable Storageの使用方法
Immutable Storageは、記録場所を構築し、構築した記録場所へ、他プログラムとの連携機能を使用して、log, hisotry, ledgerを保管、参照することで、容易に前記機能が得られます。
Immutable Storage記録場所の構築
詳しい構築方法は、以下を参照してください。
https://github.com/Hitachi/ImmutableStorage
この詳しい構築方法を参照しながら、microk8sを使用した構築方法について簡単に説明します。
Immutable Storage用Kubernetes環境の準備
Immutable Storageの記録場所は、Kubernetes (K8s)上で動作することを前提に作られています。そのためK8s環境を用意する必要があります。環境は、Google, Azure, AWSが提供するK8s環境でも動作すると思いますが、簡単に試す環境として、microk8sを使用してK8s環境を構築する方法があります。ここでは、microk8sを使用し、構築例を記載します。
microk8s自体の環境の構築には、以下を参照してください。
https://microk8s.io/
microk8s環境構築過程で、追加のserviceを有効にする際には、dns, metallb, registry, storageを有効にする必要があります。
(補足: metallb (Loadbalancer)は、K8s cluster外のプログラムと通信する必要がある時に、有効にする必要があるserviceですが、Immutable Storageでは、Immutable Storageの操作用に使用するHTTPS protocol以外にも、複数の記録場所(複数のK8s環境)に情報を複製し合うプログラム間でも使用します。記録場所が、1つのK8s環境の場合には、技術的には、Loadbalancerを使わずHTTPS protocolのみK8s環境外のプログラム(Immutable Storageと他のプログラムとの連携用プログラム)と通信できるようにもできます。Immutable Storageはsource codeを公開していますので、各環境に最適に、作成し直すことも可能です。また、Immutable Storageでは、使用するdocker imageの取得と加工のため、container内で、file mount権限(CAP_SYS_ADMIN)が必要です。microk8sでは、/var/snap/microk8s/current/args/kube-apiserverに、--allow-privileged=trueの追加を必要とする場合があります(microk8s v1.22以降では、必要ないようです)。ただし、このCAP_SYS_ADMIN権限は、Immutable Storage構築後の通常使用時には、必要ありません)
Immutable Storage docker imageの導入
以下より、docker imageを取得してください。
https://github.com/Hitachi/ImmutableStorage/releases
取得後、以下のようにImmutable StorageをK8s repositoryに導入します。
microk8s.ctr i import ImmutableStorage-1.4.0.tar
microk8s.ctr i push --plain-http localhost:32000/imms:1.4.0 localhost:32000/imms:1.4.0
Immutable Storage serviceの起動
以下の起動用構築設定例を入手してください。
https://github.com/Hitachi/ImmutableStorage/raw/b1/imms-example.yaml
以下を実行すると起動用構築設定に従いImmutable Storage serviceが起動します。なお、起動時に必要なdocker imageをInternetより入手しますので、起動時はInternetに接続できる環境である必要があります。ただし、1度起動した後は、K8sのprivate local registryにdocker imageを格納するため、通常運用中には、Internetに接続できない環境でも使用可能です。
microk8s.kubectl -f imms-example.yaml
以下を実行して、管理者用初期暗証文字列を取得します。
microk8s.kubectl logs imms
例では、以下のように、表示され、"WNB57zcz"が暗証文字列となります。
Initial administrator secret: WNB57zcz
次に、Web Browserで、Immutable Storage serviceを操作するためのIP addressを次のように入手します。
microk8s.kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ca LoadBalancer 10.152.183.132 10.64.140.43 7054:31623/TCP 3m29s
envoy LoadBalancer 10.152.183.247 10.64.140.45 8080:31144/TCP 3m28s
kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 7d
www LoadBalancer 10.152.183.104 10.64.140.44 443:30126/TCP 3m28s
この例では、www serviceのEXTERNAL-IPに表示されている10.64.140.44が取得したいIP addressです。以下のWeb Browserの画面のように、URLに取得したIP addressをhttps形式で入力し、Secretの入力に、取得した暗証文字列を入力します。その後、"Enroll user"を押すと、管理者の秘密鍵がbrowser内で生成され、公開鍵に関連した証明書をImmutable Storageより得ることができます。
その後、以下の詳しい構築方法に記載の4.2から4.4をWeb Browserの画面を見ながら実施すると、Immutable Storage記録場所は完成です(画面の通りに、操作していただければ、構築が可能と推測しますので、ここでの説明は省略します)。
https://github.com/Hitachi/ImmutableStorage
Immutable Storageと他プログラムとの連携
Immutable Storageを使用することで、既存のプログラムに、Blockchainにより得られる機能と同等の機能を追加可能です。また、新規のプログラムにも簡単に機能を追加することができます。以下は、既存または新規プログラムのWeb applicationやnative applicationが、Immutable Storageと連携することで、前記の機能を追加する方法を記載しています。
https://github.com/Hitachi/ImmutableStorage/blob/b1/doc/ImmutableStorageClient.md
Immutable Storageと連携する最も簡単な方法は、既存のプログラムには、何もプログラムを追加・変更することなく、連携する方法です。この方法は、rsyslogとImmutable Storageを連携する方法です。ただし、この方法は、追加変更しない既存プログラムが、syslogによるlogを出力するプログラム、またはファイルにlogを出力するプログラムに限ります。
rsyslogとの連携
ここでは、syslogを出力しているプロラムとsyslogとの連携をする方法を紹介します。
rsyslogとの連携プログラム動作環境
紹介するImmutable Storageとrsyslogが連携するプログラム(imm-client.rsyslog2imm)が動作する環境は、以下の環境とします。
- rsyslogを導入済み(通常debian系Ubuntu等やRedHat系CentOS等は、syslogにrsyslogを使用)
- snap packageによるpackage管理が可能(Ubuntuは通常導入済み、RedHat系CentOS等はsnapdを導入必要)
- 前記のImmutable Storage serviceと通信可能
ただし、上記のような環境でない場合、例えば、Windows環境においても、使用方法や設定を変えれば、既存プログラムの変更なしに、Immutable Storageとの連携は可能ですが、今回の紹介の範囲外とします。
連携例の紹介
Linux環境では、認証関係のlogは、/var/log/auth.logや/var/log/secureに出力されることが多いと思います。ここでは、例として、これらのlogをImmutable Storageに記録することで、logの改ざん耐性を向上させる方法について説明します。
連携用プログラムの導入
以下より、rsyslogとの連携用プログラム(imm-client.rsyslog2imm)を収めたsnap packageを入手してください。
https://github.com/Hitachi/ImmutableStorage/releases/download/v1.2.0/imm-client_1.2.0_amd64.snap
snap install ./imm-client-1.2.0_amd64.snap --devmode
連携用プログラムの設定
logをImmutable Storageに記録する記録者を作成します。Immutable Storageの管理者権限のあるadminにより、Reigisterを選択し、記録者authloggerを作成してください。
次に、以下の図のように、Enroll tabを選択し、authloggerの秘密鍵と公開鍵を作成します。(補足: この秘密鍵は、browserにより作成され、Immutable Storage serviceには保管されません。)
authloggerの秘密鍵と公開鍵の作成後、以下の図の2つのExportを順に押して、作成したprivate key (秘密鍵)とpublic key(公開鍵)を取得します。
取得した、秘密鍵(authlogger_sk)と公開鍵(authlogger.pem)を/etc/rsyslog2immに格納してください。/etc/rsyslog2immは事前にroot権限で作成してある必要があります。例えば、以下のように記録者の秘密鍵と公開鍵を格納してください(/home/immuser/Downloads内に取得した秘密鍵と公開鍵がある場合)。
また、rsyslogdの動作権限で、秘密鍵と公開鍵が読めるようにしてください(rsyslogdより参照可能な状態)。ただし、秘密鍵は、所有者(記録者)とrsyslogdのみ参照可能な状態にしてください。秘密鍵が誰でも参照可能な状態では、そもそも秘密な鍵にならないので、秘密鍵の取扱いには注意が必要です。この例では、rsyslogがsyslog user権限で動作する場合を想定して記載しています。
sudo mkdir /etc/rsyslog2imm
sudo mv /home/immuser/Downloads/authlogger* /etc/rsyslog2imm
sudo chmod 400 /etc/rsyslog2imm/authlogger_sk
sudo chown syslog.syslog /etc/rsyslog2imm/authlogger*
以下のように、/etc/rsyslog2imm/config.yamlに記載してください。ここで、URLに記載するIP addressとportは、"Immutable Storage serviceの起動"節で記載したImmutable Storage serviceを操作するためのIP addressの入手により得られます(microk8s.kubectl get svc)。この例では、envoy serviceのEXTERNAL-IPに表示される10.64.140.45とPORTに表示される8080をconfig.yamlのURLに以下のように設定します。
UserName: authlogger@example.com
KeyPath: /etc/rsyslog2imm
StorageGroup: storage-grp.example.com
URL: 10.64.140.45:8080
次に、rsyslogdの設定を追加します。追加設定は、/etc/rsyslog.d内にファイルを追加する方法である場合(Ubuntu等)には、以下の設定を60-imm-log.confとして/etc/rsyslog.dに格納して下さい。/etc/rsyslog.confのみの場合(CentOS等)には、以下の設定を/etc/rsyslog.confの最後に追加して下さい。
module(load="omprog")
if $syslogfacility-text == "auth" or $syslogfacility-text == "authpriv" then {
action(type="omprog" binary="/snap/bin/imm-client.rsyslog2imm TraditionalFormat" template="RSYSLOG_TraditionalFileFormat")
}
rsyslogdを設定後、rsyslogdを再起動してください。例えば、"systemctl restart rsyslog"により再起動してください。
なお、記録するlogは、templateにRSYSLOG_TraditinalFileFormatを指定した場合、TraditinalFileFormat形式で得られたプログラム名を記録するkey名として、Immutable Storageに記録します。templateにRSYSLOG_TraditinalFileFormatを指定しなかった場合や他のtemplateを指定した場合には、記録するプログラム名が判定できないため、imm-client.rsyslog2immに、TraditinalFormatでなく、PassThroughを指定し、続いて、記録したいkey名(プログラム名)を指定してください。
動作確認
以下のようにauth facility logが記録されるようにします。
sudo ls /tmp
Immutable Storage記録内容の確認と検証
Immutable Storage内には、主に次の図のような内容を記録します。(補足: Hyperledger Fabricを記録する部品として使用しているため、形式は、Hyperledger Fabricと同様)
図に示す通り、複数の署名により、記録内容が改ざんされたことが、検出可能な記録形式です。検証可能な記録の最小単位は、Header, Data, Metadateから構成されるblockです。記録するblockの順番が、変更困難なように、Headerには、前のblockのHeaderのSHA256 hash (Previous header checksum)と、自身のblock内DataのSHA256 hash (Data checksum)が記録され、更に、検証可能なように、Metadata内には、このhash計算を行ったstorage group serviceの証明書(Storage Group certificate)と署名内容(Signature for header)が記録されます(記録順序性保証)。記録の順番は、記録要求が、Storage Group serviceに到着した順になります。このように、信頼されるserviceの署名により、記録順序を改変しにくい構造を実現しています。この信頼される署名による順序保証方法は、消費電力に配慮した方法だと考えます(信頼できるserviceがなく、計算量により順序保証するhash値探索よりも消費電力を低く抑えることができます)。
Blockの中のData部分が、記録者(Creator)・記録要求者が、作成する部分です。Data部分には、Payload Headerに記録者の証明書(Creator certificate)と記録者時刻(Timestamp)を記録し、記録したい内容があるPayload部分の署名(Signature for payload)を記録することで、記録者が記録要求した内容(Input)と記録者の要求時刻が証明可能です。すなわち、記録者の記録要求意思を証明することができます。また、記録者が、内容を保存したいStorage serviceの署名(Signature for Action)をStorage serviceより取得し、Payloadの中に記録することで、記録後に、Storage serviceの証明書(Storage certificate)と共に、保存した記録場所の証明が可能です(改ざん耐性向上)。
ここでは、上記までに説明した改ざん耐性、記録者(意思)証明性、記録時刻・順序証明性などをより具体的に、どのように得ているのかを説明しまた。(補足: 上記の図のInputから、演算$f$(処理:action)をStorage serviceが行いKeyとValueを得ています。Immutable Storageが使用している演算$f$は、前記の実行証明性の節で記載した通り、変更を最小限にする演算で、入力(Input)に記録するべきKeyとValueを指定しているので、この指定の通り記録する演算です。この図の丸四角内がそれぞれの署名範囲を示しています。図の署名範囲からも、実行証明性で記載した内容を理解していただけると思います。)
次は、実際に、これらの特性を検証する簡単なプログラムの使い方を紹介します。
記録内容の確認と検証プログラム
前記の動作確認では、プログラムsudoにより、auth facility logを記録しました。よって、以下のように、プログラム名(Key)に"sudo"を、設定に"./immconfig.yaml"をそれぞれ指定すると、記録内容の確認と検証ができます。
imm-client.readblock sudo ./immconfig.yaml
設定は、/etc/rsyslog2imm/config.yamlで設定した内容とほぼ同じですが、authloggerの秘密鍵と公開鍵が置かれている場所を指定するKeyPathには、秘密鍵と公開鍵が、imm-client.readblock実行者にも読める場所を指定して下さい。
UserName: authlogger@example.com
KeyPath: /home/authlogger/Downloads
StorageGroup: storage-grp.example.com
URL: 10.64.140.45:8080
以下は、出力例です。
Number: 34, block size: 5100
previous header sum: 3c35800dfc73dd3adff51e1b82469ede748f0a05088de0826008fdd6eedf856e
calculated header sum: 0d44405d20f3576838bfd656e4369ff71256742f90b82ec6949888a7adbad38d
storage group: storage-grp.example.com
signature for header: 3045022100d90253f1596cd361f3e8877ce15dcbe8d864103f600542494440815ca9aedb1c02204f05025ca89fae2e62f052a0c3999e51084509a0dff16d777eba110c2068ed46: verified
contained data sum: 64d300dd123482b14fd8b24d45e91f522001d16f54c3a9638a4529090b9474cb
calculated data sum: 64d300dd123482b14fd8b24d45e91f522001d16f54c3a9638a4529090b9474cb: OK
type: ENDORSER_TRANSACTION
timestamp: Tue Nov 30 19:59:07 JST 2021
Creator: authlogger
signature for payload: 3045022100a229065f683bc639cda562bc483707653cf7da669a10d7a4ef7dacb1ebd42de0022074283763a9fa97c1ff2c091cf7975bc8e95406a7a2677eb122ecd083fded492f: verified
stored storage: storage.example.com
signature for action: 304402201d09b3a34507c6e36721057365fba67004d9101780b1eb0c8ad814e26833b99402204a7b8459a759418aac20a3077995b82f6375044d00d49f3c772a3e9575d5f62e: verified
ledger: Nov 30 19:59:07 Ex1 sudo: k8 : TTY=pts/2 ; PWD=/tmp ; USER=root ; COMMAND=/bin/ls /tmp
Nov 30 19:59:07 Ex1 sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 30 19:59:07 Ex1 sudo: pam_unix(sudo:session): session closed for user root
この例の出力のように、Headerに記録されているSHA256 hash(Data checksum)が、imm-client.readledgerが記録されているDataから計算して求めたSHA256 hashと等しい場合には、"OK"をcalculated data sumの最後に出力します。等しくないときには"NG"が表示されます。順序性は、previous header sumが、前のblock numberのcalculated header sumと等しい時、入れ替わっていないことが分かりますが、(保存要求を受けた)順序の保証は、Storage Group serviceが行ったこと、すなわち、記録するblockの前後関係を示すprevious header checksumとdata checksumの2つが含まれるheaderにStorage Group serviceが署名したことが、順序の保証となります。よって、順序性の検証は、headerとmetadataに含まれる証明書(Storage Group certificate)と署名(signature for header)により可能です。この検証は、上記の出力の中で、signature for headerの行の最後に表示される"verified"により正しく検証されたことが分かります。検証した結果が、不正である場合には、"verification failure"が表示されます。
同様に、記録者(authlogger)が、確かに記録したことの検証は、記録者が記録要求をしたpayloadと記録者の証明書(creator certificate)と記録者の署名(signature for payload)により検証可能です。出力例では、signature for payload行の最後に、検証結果に問題がないことを示す"verified"が表示されます。
更に、記録場所(Storage service)が、確かに自身が持つ記録装置に保存したことの検証は、payload (input, key, valueから構成)とStorage serviceの証明書(Storage certificate)とStorage serviceの署名(signature for action)により検証可能です。出力例では、signature for action行の最後に、検証結果に問題ないことを示す"verified"が表示されます。
以上より、記録内容に不正(改ざん等)を検出する方法は、例えば、以下のようにimm-client.readblockの出力結果を確かめる方法があります。なお、不正がない場合には、何も表示されません。不正がある場合には、"verification failure"が表示されます。
imm-client.readblock sudo ./immconfig.yaml | grep '^signature' | grep ': verification failure$'
今回の紹介した例では、不正にroot権限取得して、logを改ざんされた場合に、その改ざんをある程度検出可能であると考えます。
終わりに
今回のImmutable Storage使用例では、rsyslogと連携することで、簡単に(導入費用を少なく)、Blockchainにより得られる機能を既存プログラムに追加可能であることを示しました。このrsyslog機能連携は、今回紹介した例以外にも、例えば、入退出者を厳格に制限した場所への入退出logと連携することで、入退室logに不正がないことを入退出管理者以外の者に証明可能であったり、記録するlogを用途を変えることで、幅広く使用することができます。
また、Immutable Storageには、他にも、多くの機能を用意しています。特に、使用者の秘密鍵は使用者のみが適切に管理し使用できるように配慮し、設計しています。この特徴を生かした使用方法については、今回、紹介しきれませんでしたが、またの機会に、紹介したいと思います。
以上、ありがとうございました。
参考文献
- https://www.rsyslog.com/doc/master/index.html
- Bitcoin: A Peer-to-Peer Electronic Cash System
- Security guidelines on the appropriate use of qualified electronic seals Guidance for users VERSION 2.0 FINAL DECEMBER 2016
- Regulation (EU) No 910/2014 (elDAS) Article 36 Requirements for advanced electronic seals
- Security guidelines on the appropriate use of qualified electronic time stamps Guidance for users VERSION 2.0 FINAL DECEMBER 2016
- RFC-3161
- 公的個人認証サービスプロファイル仕様書2.0版
- https://github.com/hyperledger/fabric
- https://github.com/hyperledger/fabric-ca
- https://www.niis.org/blog/2018/4/26/there-is-no-blockchain-technology-in-the-x-road
- https://github.com/nordic-institute/X-Road
他社所有登録商標に関する表示
- Kubernetesは米国およびその他の国におけるThe Linux Foundationの登録商標です。
- UbuntuはCanonical Ltdの登録商標です。
- CentOSはRED HAT, INCの登録商標です。
- Hyperledgerは米国およびその他の国におけるThe Linux Foundationの登録商標です。
- その他記載の会社名、製品名などは、それぞれの会社の商標または登録商標です。