(57)【要約】【課題】利用者の利便性と秘密鍵管理の安全性とを両立するためのデジタルアセット管理システムの提供。【解決手段】  利用者と、サービス提供者と、管理業者との間でデジタルアセットを管理するためのデジタルアセット管理システムであって、前記デジタルアセットにアクセスするための秘密情報を秘密分散法を用いて少なくとも４つの割符に分割する割符生成手段と、前記割符のうち、所定の閾値の数以上の前記割符が集まったことを条件として前記利用者の前記アクセスを正当なものとみなすための同意判定手段と、を有し、前記割符は、少なくとも３つが常用割符として前記利用者と前記サービス提供者と前記管理業者とのそれぞれに分配され、前記割符の数と前記閾値の数との差分の数が冗長化割符として保管されることを特徴とするデジタルアセット管理システム。【選択図】図２
2020058007.tif 000002
【特許請求の範囲】
【請求項１】
利用者、サービス提供者、管理業者との間で相互に利用者のデジタルアセットを管理するためのデジタルアセット管理システムであって、
前記デジタルアセットにアクセスするための秘密情報を秘密分散法を用いて少なくとも４つの割符に分割する割符生成手段と、
前記割符のうち、所定の閾値の数以上の前記割符が集まったことを条件として前記利用者の前記アクセスを正当なものとみなすための同意判定手段と、
を有し、
前記割符は、少なくとも３つが常用割符として前記利用者と前記サービス提供者と前記管理業者とのそれぞれに分配され、前記割符の数と前記閾値の数との差分の数が冗長化割符として保管されることを特徴とするデジタルアセット管理システム。
【請求項２】
請求項１に記載のデジタルアセット管理システムにおいて、
前記割符は、４つまたは５つに分割され、前記閾値の数の２倍を超えないように分割されることを特徴とするデジタルアセット管理システム。
【請求項３】
請求項１または２に記載のデジタルアセット管理システムにおいて、
前記割符生成手段は、ハードウェアセキュリティモジュール上で前記割符の生成を行うとともに、前記割符のうち１つを前記利用者に送付されるＩＣカードに格納することを特徴とするデジタルアセット管理システム。
【請求項４】
請求項１乃至３の何れか１つに記載のデジタルアセット管理システムにおいて、
前記デジタルアセットの移転はブロックチェーン技術を用いたトランザクションとして記録され、
前記同意判定手段が前記アクセスを正当なものとみなしたことを条件として、前記トランザクションに署名が行われることを特徴とするデジタルアセット管理システム。
【請求項５】
利用者、サービス提供者、鍵管理業者、信託業者の間で相互に利用者のデジタルアセットを管理するためのデジタルアセット管理システムであって、
前記デジタルアセットにアクセスするための秘密情報を秘密分散法を用いて複数の割符に分割する割符生成手段と、
前記割符のうち、所定の閾値の数以上の前記割符が集まったことを条件として前記利用者の前記アクセスを正当なものとみなすための同意判定手段と、
前記同意判定手段が前記アクセスを正当なものとみなしたことを条件として前記割符から前記秘密情報を復号する復号手段と、
を有し、
前記割符生成手段は、前記利用者と前記サービス提供者と前記鍵管理業者と前記信託業者とに前記割符をそれぞれ送付し、
前記利用者の指示に基づいて、前記デジタルアセットを混蔵保管することを特徴とするデジタルアセット管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタルアセット管理システムに関する。
【背景技術】
【０００２】
近年では仮想通貨、暗号通貨、コイン、トークン等の様々な電子情報によって構成された資産（デジタルアセット）を活用する機会が増加してきている。
こうしたデジタルアセットの管理を行う上では、秘密鍵と公開鍵のペアを生成し、秘密鍵を知っていることを以て本人であることを確認する、所謂公開鍵暗号方式が広く用いられている。
しかしながら、このように秘密鍵を用いて本人であることを証明するシステムでは、秘密鍵の盗難や紛失等のリスクが非常に高くなってしまうという課題があった。
また、秘密鍵の厳密な管理は、サービスの利用者にとってはハードルが高く、利便性の低下につながってしまうという懸念も生じていた。
このような課題を解決する方法の１つとして複数人でトランザクションへの署名を行う所謂マルチシグ等の方法も考えられてはいるが、利便性とセキュリティ向上との両立が十分になされているとは言い難い。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−２３１４０４号公報
【特許文献２】特開２００７−４２０２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、かかる問題を解決するためのものであり、利用者の利便性と秘密鍵管理の安全性とを両立するためのデジタルアセット管理システムの提供を目的とする。
【課題を解決するための手段】
【０００５】
上述した課題を解決するため、本発明のデジタルアセット管理システムは、前記デジタルアセットにアクセスするための秘密情報を秘密分散法を用いて少なくとも４つの割符に分割する割符生成手段と、前記割符のうち、所定の閾値の数以上の前記割符が集まったことを条件として前記利用者の前記アクセスを正当なものとみなすための同意判定手段と、を有し、前記割符は、少なくとも３つが常用割符として前記利用者と前記サービス提供者と前記管理業者とのそれぞれに分配され、前記割符の数と前記閾値の数との差分の数が冗長化割符として保管されることを特徴とする。
【発明の効果】
【０００６】
本発明によれば、デジタルアセットの使用に必要な秘密情報を安全に管理することができる。
【図面の簡単な説明】
【０００７】
【図１】本発明の実施形態に係る情報処理システムの全体構成の一例を示す図である。
【図２】本発明の管理システムの動作の一例を示す図である。
【図３】本発明の実施形態に用いられる秘密分散法の概念を示す図である。
【図４】本発明の実施形態における管理システムのデータの流れを示す図である。
【図５】本発明の実施形態における管理システムの動作の一例を示す図である。
【図６】デジタルアセットの管理の従来例を示す図である。
【図７】本発明の実施形態において、割符の紛失時に用いられる秘密分散法の概念を示す図である。
【図８】本発明の実施形態において、割符を更に分散する方法の概念図である。
【図９】本発明の実施形態において、割符を更に分散することで非活性化する方法の概念図である。
【図１０】本発明の第３の実施形態における鍵の割符の分配を模式的に示した図である。
【図１１】本発明の第３の実施形態における送金フローと混蔵保管のフローとを模式的に示す図である。
【図１２】本発明の第３の実施形態における引き出しフローを示す図である。
【発明を実施するための形態】
【０００８】
本発明の第１の実施形態として、ビットコインなどの仮想通貨と現実の貨幣等を交換する仮想通貨取引所のシステムを用いて説明を行う。
なお、以降の説明において、「デジタルアセット」とは仮想通貨、暗号通貨、コイン、トークン等の様々な電子情報によって構成された資産を指し、デジタルアセットの管理とは、かかる資産を構成する電子情報を適切に取り出し可能に保管することを言う。デジタルアセットの管理には例えば本実施形態に於いて述べるような保管の他、利用者の同意に基づいて運用を行う所謂信託のような業態や、支払い決済の代行等を含んでも良い。
【０００９】
管理システム１００は、利用者Ｐに送付されるＩＣカード１０と、利用者Ｐが用いる端末１１と、利用者Ｐに対して仮想通貨の交換サービスを提供するサービス提供者Ｑが有するサーバ２０と、保管代行業者Ｒの備える管理用サーバ３０と、を含んだネットワーク９上に構成される情報処理システムである。
【００１０】
なお、本実施形態においては特に、サービス提供者Ｑは仮想通貨の交換業を行う仮想通貨交換業者であるとし、かかるサービス提供者Ｑに預けられたデジタルアセットの管理業務を行う管理業者が保管代行業者Ｒである。
【００１１】
ＩＣカード１０は、後述する割符５１Ａがデータとして内部に格納されたカードである。端末１１は、かかるＩＣカード１０を読み取るカードリーダとしての機能を有するパソコンあるいはその他電子計算機を含む電子機器である。
【００１２】
サーバ２０は、端末１１から送付されてきた割符５１Ａをサービス提供者Ｑの保管する割符５１Ｂと合成するハードウェアセキュリティモジュールたる第１ＨＳＭ２１と、利用者Ｐの登録を行う登録手段としての認証用ＤＢ２２と、を有している。
【００１３】
管理用サーバ３０は、保管代行業者Ｒの割符５１Ｃを有する割符ＤＢ３２と、サーバ２０から送付されてきた割符５１Ａと割符５１Ｂとの合成割符を割符５１Ｃと合成するハードウェアセキュリティモジュールたる第２ＨＳＭ３１と、を有している。
ハードウェアセキュリティモジュールは、耐タンパー性（物理的あるいは論理的な攻撃に対する耐性）を備え、複号中や計算中の秘密情報（本実施形態では暗号鍵）の外部からの読取が不可能なハードウェアである。
なお、本実施形態においては、第２ＨＳＭ３１が、割符生成手段としての機能を有している。また、第１ＨＳＭ２１と、第２ＨＳＭ３１とが同意判定手段を構成している。かかる機能については、図２を用いて後述する。
【００１４】
まず、利用者Ｐが仮想通貨交換業者であるサービス提供者Ｑのサーバ２０に接続して、認証用ＤＢ２２にユーザとして登録すると、サーバ２０は、かかる利用者Ｐの登録情報に基づいて管理用サーバ３０に一対の鍵ペアの生成を申請する（ステップＳ１０１）。
【００１５】
次に管理用サーバ３０は、第２ＨＳＭ３１上で乱数から一対の公開鍵５０と秘密鍵５１との鍵ペアを生成する（ステップＳ１０２）。なお、かかる鍵生成は、一般的なＲＳＡ暗号方式を用いても良いし、その他の公開鍵暗号方式を用いても構わない。
【００１６】
第２ＨＳＭ３１はさらに、ステップＳ１０２において生成された公開鍵５０と秘密鍵５１とを、利用者Ｐのデジタルアセットに紐づける（ステップＳ１０３）。
第２ＨＳＭ３１は、秘密鍵５１を秘密情報として、秘密分散法によって割符５１Ａ〜割符５１Ｄの４つに分割する（ステップＳ１０４）。
なお、以降は、閾値３に設定したシャノアの秘密分散法を用いて、説明を行う。
かかる割符５１Ａ〜５１Ｄは、それぞれ所定のデータ型なるように形成されたデータ群であって、割符５１Ａ〜５１Ｄのうち、何れか３つ以上が集まったときに、元となった秘密情報である秘密鍵５１を復元可能な分割データである。
また、図３から明らかなように、割符５１Ａ〜５１Ｄは、閾値の数である３未満すなわち何れか１つあるいは２つが盗み見られた場合であっても、それぞれはデータ群に過ぎないため、秘密鍵５１を復元することができないという特性を有している。
【００１７】
このような秘密分散法について、図３を用いて概略を説明する。
図３に示したように、秘密情報となる秘密鍵５１がｆ（ｘ＝０）の解となる任意の２次関数ｆ（ｘ）を仮定する。
このとき、関数ｆ（ｘ）は、閾値の数３とすると、閾値の数−次数が１となるように、次数が２であることが望ましい。
第２ＨＳＭ３１は、かかる関数ｆ（ｘ）上の任意の４点を、割符５１Ａ〜５１Ｄとして引数を返す。
【００１８】
このとき、割符５１Ａ〜５１Ｄは何れもバラバラで単体では情報を持たない単なる数字であるが、『与えられた３つあるいは４つの点を全て通る次数２の関数』であることが分かっていれば、その関数ｆ（ｘ）は一意に求められる。このように関数ｆ（ｘ）がわかると、ｆ（ｘ＝０）も明らかとなるため、秘密情報である秘密鍵５１がわかる。なおここでｘ＝０の解を秘密鍵５１としたが、かかる構成に限定されるものではなく、任意のｆ（ｘ）上の点であって良い。
秘密分散法は、このような仕組みを用いて、データ群である割符５１Ａ〜５１Ｄを用いて、秘密鍵５１を復元する。
なお、ここでは２次関数を用いているが、かかる構成に限定されるものではなく、閾値の数より１だけ小さい次数を持つ関数であれば良い。ただし、５次以上の方程式については一般に代数的には解けないため用いられない。従って、閾値の数は２以上５以下である。
【００１９】
第２ＨＳＭ３１は、このような秘密分散法を用いて割符５１Ａ〜５１Ｄを生成するとともに、そのうちの割符５１ＡをＩＣカード１０に格納する（ステップＳ１０４）。
ステップＳ１０４においてＩＣカード１０に割符５１Ａが電子データとして格納されると、保管代行業者Ｒは、ＩＣカード１０を利用者Ｐに送付して（ステップＳ１０５）、利用者Ｐの仮想通貨と、公開鍵５０とが紐づけられる。
保管代行業者Ｒはさらに、ステップＳ１０４で生成した割符５１Ｂをサービス提供者Ｑのサーバ２０へと送信し、割符５１Ｃを保管代行業者Ｒの有する割符ＤＢ３２に保管する（ステップＳ１０５）。
割符５１Ｄは、例えば割符ＤＢ３２にバックアップ用として保管される。なお、割符５１Ｄの保管場所は、かかる構成に限定されるものではなく、信頼できる第三者に送付して保管してもらうのでも良いし、利用者Ｐまたはサービス提供者Ｑが保持しても良い。
かかる割符５１Ｄは、後述するように、ＩＣカード１０を紛失した際にバックアップとして機能する冗長化割符である。
【００２０】
このようにして、利用者Ｐ、サービス提供者Ｑ、保管代行業者Ｒのそれぞれが割符５１Ａ、割符５１Ｂ、割符５１Ｃを所持した状態で、利用者Ｐが秘密鍵５１を用いて自身のデジタルアセットにアクセスする場合の処理を図４、５に示す。
【００２１】
まず、利用者Ｐが、端末１１にＩＣカード１０を挿入し、サーバ２０へと接続すると、端末１１はＩＣカード１０から割符５１Ａを読みだして第１ＨＳＭ２１へと送信する（ステップＳ２０１）。
次に、第１ＨＳＭ２１は、認証用ＤＢ２２から割符５１Ｂを受け取り、ステップＳ２０１において受け取った割符５１Ａと合成して割符５１Ａ＋Ｂを生成する（ステップＳ２０２）。
【００２２】
ステップＳ２０２で合成された割符５１Ａ＋Ｂは、管理用サーバ３０の第２ＨＳＭ３１へと送信される（ステップＳ２０３）。
第２ＨＳＭ３１は、割符ＤＢ３２から割符５１Ｃを受け取って、割符５１Ａ＋Ｂと合成する（ステップＳ２０４）。
【００２３】
このように割符５１Ａ〜Ｃを常用割符として用い、割符５１Ａ〜ＣがステップＳ２０４において合成されたことをもって、第２ＨＳＭ３１は復号した秘密鍵５１を用いて利用者Ｐの送信したトランザクションに署名を行う（ステップＳ２０５）。
すなわち第２ＨＳＭ３１は、４つの割符５１Ａ〜５１Ｄのうち、少なくとも３つが第２ＨＳＭ３１に集まったことを条件として、秘密鍵５１を復元し、秘密鍵５１を用いてトランザクションに対して署名を行う同意判定手段としての機能を有している。
かかる構成にすることで、秘密鍵５１がハードウェアセキュリティモジュール上のみで復元されるから、外部からの読取に対して強い安全性を維持することができる。
また、割符５１Ａ〜５１Ｃを常用割符として、利用者Ｐ、サービス提供者Ｑ、保管代行業者Ｒの三者に配布するから、三者の同意に基づいて、デジタルアセットの管理をすることができる。
【００２４】
ここでデジタルアセットとは例えば仮想通貨等の電子データで構成された資産を示し、デジタルアセットの管理とは、かかるデジタルアセットを使用して何らかのサービスを受けたり、決済を行ったりする行為を指す。
すなわち、本実施形態では、管理システム１００は、『デジタルアセットのアクセスによって決済が承認される承認手段を有し、デジタルアセットを用いた支払い決済を行う』構成を有している。このとき、第２ＨＳＭ３１の署名によって、デジタルアセットのアクセスが承認されるから、第２ＨＳＭ３１は、承認手段としての機能を有している。
【００２５】
また、かかる構成において、かりに何れかの常用割符５１Ａ、５１Ｂ、５１Ｃのうち１つが紛失したり、盗難されてしまった場合であっても、秘密鍵５１を復号するには閾値の数以上の割符を集める必要があるため、管理システム１００は割符５１Ａ〜５１Ｃの紛失や盗難に対して強固なセキュリティを持つ。
【００２６】
ところで、従来の仮想通貨取引においては、仮想通貨の所謂ウォレットと秘密鍵とが関連付けて保管されている。そのため秘密鍵管理においては図６に示すように、利用者Ｐ’が自身の秘密鍵５１’を管理し、トランザクションに署名を行うことで自身の行う決済や移転の同意をするのが一般的であった。
しかしながら、例えば従来の銀行ＡＴＭ等のように、秘密鍵５１’をＩＣカード１０’に格納して運搬するような形態をとると、ＩＣカード１０’の不正な読取や、紛失、盗難等が生じたとき、利用者Ｐ’もサービス提供者Ｑ’も、自身のデジタルアセットをいかなる手段でも取り返すことが困難であるという問題が生じていた。
このような問題点を解決するために、トランザクションに複数の署名で承認を行う、所謂マルチシグ等の方法が考えられているが、利用者Ｐ’、サービス提供者Ｑ’、それぞれの署名を必要とするから、何れか１方が失われてしまうと、やはり自身のデジタルアセットの移動が不可能になってしまうという困難性がある。そのため、例えば秘密鍵５１’を可搬性のあるＩＣカード１０’に格納するような用途には向かなかった。
【００２７】
他方、管理システム１００において、例えばＩＣカード１０を紛失した場合を考える。
本実施形態において既に述べたように、ＩＣカード１０内部に格納された割符５１Ａは、それ単体では署名を行うことは不可能である。
また、割符５１Ａから秘密鍵５１を復号するためには、割符５１Ｂ、割符５１Ｃが必要となるから、かりに割符５１Ａが流出してしまったとしても、利用者Ｐのデジタルアセットは守られた状態が維持される。
【００２８】
従って、本実施形態ではＩＣカード１０をかりに紛失したとしても、利用者Ｐから速やかにサービス提供者Ｑに連絡をし、かかる割符５１Ａを使用不可能にするとともに、冗長化割符５１Ｄを用いて、割符５１Ｂ、５１Ｃ、冗長化割符５１Ｄの３つから、デジタルアセットの管理が可能となるように構成されている。
具体的には、利用者Ｐからの連絡を受けたサービス提供者Ｑが、管理用サーバ３０にアクセスし、再度ステップＳ１０１〜Ｓ１０５のように手続きを進めることで、割符の再発行を容易に行うことができる。
また、このとき、新たに生成された鍵ペアを公開鍵６０と秘密鍵６１とし、図７に示すように秘密鍵６１の割符６１Ａ〜６１Ｄとすれば、秘密鍵６１に利用者Ｐのデジタルアセットを紐づけるときには、割符５１Ｂ〜５１Ｄを用いて旧秘密鍵５１を復号し、旧秘密鍵５１と紐づいたウォレットから秘密鍵６１と紐づいた新たなウォレットへのトランザクションを旧秘密鍵５１を用いて署名すれば良い。
【００２９】
あるいは、同じ秘密鍵５１に対して異なる関数ｇ（ｘ）を用いて新たな割符５１Ｅ、５１Ｆ、５１Ｇ、５１Ｈを設けるとしても良い。
このように同一の秘密鍵に対して異なる関数を用いることとすれば、デジタルアセットの移転が必要ではなくなるというメリットがあるが、セキュリティ向上の観点からすると、異なる秘密鍵に異なる関数を用いた方が好ましい。
【００３０】
すなわち、本実施形態では、第２ＨＳＭ３１は『デジタルアセットにアクセスするための秘密鍵５１を秘密分散法を用いて少なくとも４つの割符に分割する割符生成手段と、割符５１Ａ〜５１Ｄのうち、所定の閾値の数３以上の割符が集まったことを条件として利用者Ｐのアクセスを正当なものとみなすための同意判定手段と』を有している。
また、管理システム１００において、『割符５１Ａ〜５１Ｄは、少なくとも３つが常用割符として利用者Ｐとサービス提供者Ｑと保管代行業者Ｒとのそれぞれに分配され、割符の数と閾値の数との差分の数が冗長化割符として保管される』。
かかる構成により、冗長化割符５１Ｄがあることで、常用割符５１Ａがかりに失われてしまったときにも、利用者Ｐのデジタルアセットを失うことなく、新たな割符６１Ａ〜６１Ｄを容易に再発行することができる。
【００３１】
また、本実施形態では、『割符生成手段は、ハードウェアセキュリティモジュール上で割符５１Ａ〜５１Ｄの生成を行うとともに、割符のうち１つを利用者Ｐに送付されるＩＣカード１０に格納する』構成を有している。
かかる構成により、利用者Ｐは、ＩＣカード１０を持ち歩くことで、端末１１を経由してサーバ２０に接続することで容易に自身のデジタルアセットにアクセスすることが可能となる。
【００３２】
また本実施形態では、『デジタルアセットの移転はブロックチェーン技術を用いたトランザクションとして記録され、同意判定手段がアクセスを正当なものとみなしたことを条件として、トランザクションに署名が行われる』構成を有している。
かかる構成によれば、利用者Ｐは、自身の仮想通貨用のウォレットから、仮想通貨の支払いを簡易に行うことができるから、仮想通貨の利便性が向上する。
【００３３】
さらに、第１の実施形態の応用例として、図８に第２の実施形態を説明する。
第２の実施形態においては、第１の実施形態で生成された冗長化割符５１Ｄまたは割符５１Ｃを、更に秘密分散法を用いて割符を生成する。
図８に示すように、割符生成手段たる第３ＨＳＭ９１が、かかる冗長化割符５１Ｄの割符として、割符９１Ａ〜９１Ｄを生成する。
かかる割符９１Ａ〜９１Ｃを、ハードウェアセキュリティモジュール上で合成することによって、割符５１Ｄを取り出すことができるようになるとすれば、例えば割符９１Ａ〜９１Ｄをそれぞれ異なるデータセンター９２Ａ〜９２Ｄで保管することで、リスク分散を行うことができる。
このように、割符を受け取ったものが更に割符を生成する割符生成手段として機能することで、セキュリティを維持しつつも災害などによるデータセンターの物理的破損についてのリスク分散を行うことができる。
【００３４】
このように、第２の実施形態における管理システム１００は、『秘密情報を導出する秘密情報生成手段』でありかつ『前記秘密情報に基づいて複数の割符を生成し、当該割符の少なくとも１つを送付する割符生成手段』としてのハードウェアセキュリティモジュールたる第２ＨＳＭ３１と、『前記割符を送付する際に当該割符を非活性化する非活性化手段』としての第３ＨＳＭ９１とを有している。
かかる構成において、非活性化手段は割符５１Ｄを更に割符９１Ａ〜９１Ｄへと変換することで、単体では秘密情報である秘密鍵５１を復号できなくする、すなわち割符の非活性化を行っている。このように、秘密鍵５１の割符５１Ａ〜Ｄを更にそれ単体では用いることができないようにすることを、『非活性化』と称している。また、本実施形態における第３ＨＳＭ９１は何所に置かれていても良い。また、第１ＨＳＭ２１や第２ＨＳＭ３１が非活性化手段として、割符５１Ａ〜５１Ｄの何れかあるいは複数を分割して割符化する構成であっても良い。
【００３５】
なお、非活性化手段はかかる構成に限定されるものではなく、例えば図９に示すように、秘密鍵５１から２つの割符５１Ａ、５１Ｂを生成したあと、割符５１Ａを更に割符５１ａ、５１ｂへと分割して、利用者Ｐとサービス提供者Ｑへとそれぞれ送付することとしても良い。
このような場合には、第１ＨＳＭ２１は、割符５１ａと割符５１ｂとを用いて割符５１Ａを復元し、かかる割符５１Ａを第２ＨＳＭ３１へと送付する。
第２ＨＳＭ３１は、割符５１Ａと割符５１Ｂとを用いて秘密情報である秘密鍵５１を復号化することができる。
【００３６】
また、このように割符を割符化することのみならず、例えば利用者Ｐの端末１１の公開鍵暗号を用いた暗号化によって非活性化するとすれば、利用者Ｐの端末１１の秘密鍵によってのみ復号化できるので、よりセキュリティが向上する。このように『非活性化』は暗号化や割符化等の概念を含み、かかる暗号化に用いる鍵は、公開鍵暗号方式における公開鍵や秘密鍵の他、任意の共通鍵を用いても良い。
このような非活性化手段を用いることによれば、鍵が外部には露出せずに鍵生成手段から非活性化した状態で送付されるから、より安全に割符のやり取りを行うことが可能となる。
【００３７】
また、管理システム１００が非活性化手段を有するときには、上述のように、第１ＨＳＭ２１、第２ＨＳＭ３１が生成する常用割符の数は最低２つ以上であればよい。
また、第１の実施形態において述べたような冗長化割符を設けるとしても良い。
【００３８】
また、第１、第２の実施形態においては、何れも認証用ＤＢ２２、割符用ＤＢ３２、をそれぞれサービス提供者Ｑ、保管代行業者Ｒがそれぞれ管理するサーバーであるとしたが、かかる構成に限定されるものではない。
例えば、図８に示すように、外部の認証システム２３と、認証システム２３からの認証に基づいてユーザーが正当なものであると認可する認可システム２４Ｑ、２４Ｒとを有し、かかる認可システム２４Ｑ、２４Ｒからの認可に基づいてそれぞれの所持する割符５１Ｂ、５１Ｃを送信する構成であっても良い。また、認可システム２４Ｑ、２４Ｒは別体であっても同一のシステムであっても良い。
【００３９】
さて、本発明の第３の実施形態として、デジタルアセットを用いた資産信託モデルについて説明する。
本実施形態におけるデジタルアセット管理システムの一例として、管理システム２００を図１０に示す。なお、図１０において、第１の実施形態と同様の構成については、同一の付番をして説明を省略する。
管理システム２００において、利用者Ｕ、仮想通貨交換業者たるサービス提供者Ｅｘ、利用者Ｕの秘密情報たる秘密鍵５１を管理するための鍵保管業者Ｕｃ、サービス提供者Ｅｘのウォレットの管理を行うための信託管理業者Ｅｃ、秘密情報から秘密鍵を生成するプロセッシングセンタＰＵとして説明を行う。
【００４０】
管理システム２００においては、まず利用者Ｕがサービス提供者Ｅｘに申し込みを行うと、サービス提供者Ｅｘは利用者Ｕの本人確認や審査等を行った後、プロセッシングセンタＰＵにＩＣカード１０の発行指示を出す。
プロセッシングセンタＰＵがかかる発行指示を受け取ると、第２ＨＳＭ３１は、まず秘密鍵５１を秘密情報として、秘密分散法によって割符５１Ａ、５１Ｂ、５１Ｃ、５１Ｄの４つに分割する。ここでは、秘密分散法における閾値は３であり、割符の数は４であるが、かかる構成に限定されるものではなく、第２の実施形態のように割符５１Ａ〜５１Ｄをさらに秘密分散法を用いて分散して非活性化するとしても良い。本実施形態においては、プロセッシングセンタＰＵの備える第２ＨＳＭ３１が割符生成手段としての機能を有しているが、他のＨＳＭで割符を生成するとしても良い。また、プロセッシングセンタＰＵは、本実施形態では秘密情報の管理上、鍵保管業者Ｕｃ、サービス提供者Ｅｘ、信託管理業者Ｅｃ、とは別個の独立した機能として記載するが、例えば信託管理業者Ｅｃや鍵保管業者Ｕｃが割符生成手段を備えていても良い。
かかる割符５１Ａ、５１Ｂを、鍵保管業者Ｕｃの公開鍵を用いて暗号化した上で、ＩＣカード１０に格納して利用者Ｕへ、割符５１Ｂをサービス提供者Ｅｘへ、割符５１Ｃを鍵保管業者Ｕｃへ、それぞれ送付する。なお割符５１Ｄはバックアップとして任意の保管場所に保管して良い。ここで鍵保管業者Ｕｃ、信託管理業者Ｅｃは、何れもカストディアンであり、鍵保管業者Ｕｃは利用者と契約し、Ｅｃはサービス提供者Ｅｘと契約してデジタルアセットを保管・管理する。また、信託管理業者Ｅｃと契約する所謂トラスティを信託業者Ｔで表す。
【００４１】
また、第２ＨＳＭ３１は、サービス提供者Ｅｘに対応する信託管理業者Ｅｃの混蔵保管用のウォレットＭの公開鍵８０及び秘密鍵８１の鍵ペアを生成する。
混蔵保管用のウォレットＭの秘密鍵８１は、割符８１α、８１β、８１γ、８１δに秘密分散法によって分けられて、それぞれＩＣカード１０、サービス提供者Ｅｘ、信託管理業者Ｅｃが管理する。
すなわち、ＩＣカード１０には、利用者Ｕのウォレットの秘密鍵５１に対応する割符５１Ａと、サービス提供者Ｅｘに対応する信託管理業者Ｅｃの混蔵保管用のウォレットＭの秘密鍵８１の割符８１αとが備えられている。
また、ＩＣカード１０には、利用者Ｕ、サービス提供者Ｅｘ、鍵管理業者Ｕｃ、信託管理業者Ｅｃ、プロセッシングセンタＰＵ、それぞれのＸ５０９等の規格に沿ったデジタル証明書が内蔵されているとしても良い。このようにＩＣカード１０にデジタル証明書を内蔵することによって、以降に述べるそれぞれの処理において、ＩＣカード１０から送付した情報が正しく署名された本人による処理であることを検証できるためセキュリティがさらに向上する。
なお、割符８１δはバックアップ用であって、例えば信託業者Ｔが保管することが望ましいが、任意の保管場所に保管されるとしても良い。
【００４２】
所謂資産信託においては、利用者Ｕの預けた資産すなわちデジタルアセットは、預けた利用者Ｕごとに個別に保管されるのではなく、他に預けた者のデジタルアセットと区別することなく保管される（混蔵保管）。
しかしながら、従来の仮想通貨等においては、既に図６等で説明したように、ウォレットと秘密鍵５１’とが１対１で結びついているために、ウォレットから他のウォレットへの移動には秘密鍵５１’を用いる必要がある。すなわち混蔵保管を行うためには、秘密鍵５１を他者に委ねなければならないという潜在的なセキュリティーホールが存在している。そのため、仮想通貨における信託業務は困難であった。
【００４３】
本発明の第３の実施形態においては、管理システム２００を用いてかかる混蔵保管を可能にするシステムについて説明する。
図１１に示したようにそれぞれに割符５１Ａ〜５１Ｄが割り当てられた状態から、まず利用者Ｕがサービス提供者Ｅｘの特定のウォレットに送金する場合について説明する。
利用者Ｕが送金を行うときには、まず利用者Ｕの所持するＩＣカード１０を端末１１に読み込ませ、ＩＣカード１０内に格納され鍵保管業者Ｕｃの公開鍵で暗号化された割符５１Ａを、利用者Ｕのデジタル証明書を添付した上で第１ＨＳＭ２１へと送付する（ステップＳ３０１）。
第１ＨＳＭ２１は、ステップＳ３０１で送付された内容に加えて、サービス提供者Ｅｘの有する割符５１Ｂを付加して、第２ＨＳＭ３１へと送付する（ステップＳ３０２）。
第２ＨＳＭ３１は、ステップＳ３０２において送付されたデータが、利用者Ｕの指示に基づいて送付されたものであることを利用者Ｕのデジタル証明書を用いて確認する（ステップＳ３０３）。
【００４４】
第２ＨＳＭ３１は、利用者Ｕとサービス提供者Ｅｘとのデジタル証明書等のステップＳ３０３において送付された内容を確認し、割符５１Ａ、５１Ｂを取得すると、鍵管理業者Ｕｃに対して割符５１Ｃを出す指示を出すとともに、割符５１Ａ、５１Ｂを送付する（ステップＳ３０４）。
鍵管理業者Ｕｃは、第３ＨＳＭ４１内において、割符５１Ａ〜Ｃを用いて秘密鍵５１を復号する（ステップＳ３０４）。かかる秘密分散法においては、閾値３であるので、秘密鍵５１は割符５１Ａ〜Ｃによって復号可能である。
第３ＨＳＭ４１は、トランザクションに、復号された秘密鍵５１を用いて署名を行うことで、利用者Ｕの送金処理を行うことができる（ステップＳ３０５）。このとき、第３ＨＳＭ４１は、秘密情報を割符から復元する復号手段であるとともに、トランザクションを処理する決済手段としての機能を有している。
【００４５】
次に、利用者Ｕのウォレット内のデジタルアセットを、サービス提供者Ｅｘが信託管理業者ＥｃのウォレットＭへと混蔵保管する処理について述べる。
混蔵保管を行う際には、第１ＨＳＭ２１が利用者Ｕから割符８１αを取得し（ステップＳ３１１）、サービス提供者Ｅｘの割符８１βとそれぞれのデジタル証明書を合わせて送付する（ステップＳ３１２）。
第１ＨＳＭ２１は、ステップＳ３１２において送付されたデジタル証明書から利用者Ｕが正当に認証されると、かかる割符８１α、８１βを第２ＨＳＭ３１へと送信する（ステップＳ３１３）。
同時に、サービス提供者Ｅｘから、サービス提供者Ｅｘの契約する信託管理業者Ｅｃへと混蔵指示が送信され（ステップＳ３１４）、信託管理業者Ｅｃの割符８１γが第２ＨＳＭ３１へと読み出される（ステップＳ３１５）。
第２ＨＳＭ３１は、かかる割符８１α、８１βと、鍵保管業者Ｕｃの有する割符８１γとを合成することで、ステップＳ３０４で示したのと同様に秘密鍵８１を復号し、利用者Ｕのウォレットから信託管理業者Ｅｃの混蔵保管用のウォレットＭへとデジタルアセットを移すことができる（ステップＳ３１６）。
【００４６】
このように、秘密分散法による割符を用いることによれば、秘密鍵５１を復号することが可能なのは第２ＨＳＭ３１のみであり、かつ、利用者Ｕ、サービス提供者Ｅｘ、信託管理業者Ｅｃ、鍵保管業者Ｕｃの４者のうち、少なくとも３者の合意が得られなければデジタルアセットを移管することができない。
さらに、利用者Ｕ、サービス提供者Ｅｘ、信託管理業者Ｅｃ、鍵保管業者Ｕｃのそれぞれは割符を有するに過ぎないため、それぞれの割符が仮に漏洩したとしても秘密鍵５１、秘密鍵８１を復号することは困難である。
【００４７】
かかる構成により、混蔵保管を行う場合にも、秘密鍵５１を耐タンパ性を有する第２ＨＳＭ３１上においてのみ扱うことができる。
【００４８】
さらに、従来の信託業においては、混蔵保管のみならず、顧客の資産が信託保全されていることが重要である。
本実施形態のデジタルアセット管理システム２００においては、混蔵保管されたウォレットＭのデジタルアセットをサービス提供者Ｅｘ、信託管理業者Ｅｃ、信託業者Ｔ、との間で割符８１β、割符８１γ、割符８１δの３つの割符を用いて信託管理業者ＥｃのウォレットＭから信託業者Ｔの管理するウォレットに移転することとすれば、信託業者Ｔが利用者Ｕの資産をサービス提供者Ｅｘから倒産隔離することができる。
このような構成においては、例えばサービス提供者Ｅｘが破産してしまったときにも、信託業者Ｔの管理するウォレットは保全され、さらに割符８１β、割符８１γ、割符８１δが揃えば当該ウォレットから引き出すことも可能となる。
【００４９】
次に、利用者Ｕが、利用者Ｕのウォレット内のデジタルアセットを引き出す処理について述べる。なお、既に述べたように、かかるデジタルアセットは、信託管理業者Ｅｃの混蔵保管用のウォレットＭに格納された状態である。
【００５０】
利用者Ｕが引き出し処理を行うときには、利用者Ｕの所持するＩＣカード１０を端末１１に読み込ませ、ＩＣカード１０内に格納された割符８１αを、第１ＨＳＭ２１へと送付する（ステップＳ３２１）。
第１ＨＳＭ２１は、ステップＳ３２１で送付された内容に加えて、サービス提供者Ｅｘの有する割符８１βを付加して、サービス提供者Ｅｘのデジタル証明書を添付した上で信託管理業者Ｅｃの第３ＨＳＭ９１へと送付する（ステップＳ３２２）。
第３ＨＳＭ９１は、ステップＳ３２２において送付されたデータが、サービス提供者Ｅｘの指示に基づいて送付されたものであることを利用者Ｕのデジタル証明書を用いて確認する（ステップＳ３２３）。
【００５１】
第３ＨＳＭ９１は、ステップＳ３２３において送付された内容から、割符８１α、８１βを取得すると、割符８１γを合わせて秘密鍵８１を復号する（ステップＳ３２４）。
第３ＨＳＭ９１は、トランザクションに、復号された秘密鍵８１を用いて署名を行うことで、混蔵保管用のウォレットＭから利用者Ｕへの出金処理を行うことができる（ステップＳ３２５）。
なお、第３の実施形態においては、冗長化割符を用いない場合についてのみ述べたが、第１の実施形態において既に述べたように、冗長化割符を第３の実施形態において適用するとしても良い。
【００５２】
以上本発明の好ましい実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、上述の説明で特に限定していない限り、特許請求の範囲に記載された本発明の趣旨の範囲内において、種々の変形・変更が可能である。
【００５３】
例えば、本実施形態では、常用割符５１Ａ〜５１Ｃを３つ、冗長化割符を１つの構成について説明したが、全体の割符の数を３として、常用割符を２つ、冗長化割符を１つとする構成であっても良い。
【００５４】
本発明の実施の形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施の形態に記載されたものに限定されるものではない。
【符号の説明】
【００５５】
１０        ＩＣカード
１１        端末
２０        サーバ
２１        同意判定手段（第１ＨＳＭ）
２２        認証用ＤＢ
３０        管理用サーバ
３１        同意判定手段、割符生成手段（第２ＨＳＭ）
３２        割符ＤＢ
８１        秘密鍵（秘密情報）
９１        復号手段、割符生成手段（第３ＨＳＭ）
１００      管理システム
２００      管理システム
Ｐ、Ｕ          利用者
Ｑ、Ｅｘ          サービス提供者
Ｒ（Ｅｃ、Ｕｃ）          保管代行業者
Ｔ              信託業者
【図１】
2020058007.tif 000003
【図２】
2020058007.tif 000004
【図３】
2020058007.tif 000005
【図４】
2020058007.tif 000006
【図５】
2020058007.tif 000007
【図６】
2020058007.tif 000008
【図７】
2020058007.tif 000009
【図８】
2020058007.tif 000010
【図９】
2020058007.tif 000011
【図１０】
2020058007.tif 000012
【図１１】
2020058007.tif 000013
【図１２】
2020058007.tif 000014