第２１９号コラム：佐藤 慶浩 理事（日本ヒューレット・パッカード株式会社
個人情報保護対策室 室長）
題：「情報量のないデータの流出は情報の流出になるか？」
情報セキュリティの事故はあとを絶たないが、だからといって「事故前提社会」という表現が日本語として正しくないことは、『「事故前提社会」は誤用である』（ http://yoshihiro.cocolog-nifty.com/postit/2008/09/post-da59.html ）で述べたとおりである。そこで正しくは、「事故想定社会」か「事故対応前提社会」であるが、前者は予防であり、後者は事後対応のこととなる。ここでは、前者の予防について考えてみる。
情報セキュリティ事故の中に、情報の流出や紛失、毀損などがあるが、これらは当然のことながら「情報」に対するものである。情報として意味をなさないデータの羅列であれば、それを情報の事故とは言わない。そうでなければ、一度でも情報を書き込んだハードディスクは、それをどう処理しようとも、物理的な流出や紛失が、情報の事故になってしまう。ハードディスクを廃棄するときの適切な処理とは、情報を復元不可能な状態にすることであって、そこにデータが何も残っていない状態にすることを求めるものではない。たとえば、情報として意味を持たないランダムな値を書き込むことで、そこにランダムな値はあるが、情報量はないと判断することになる。本稿では文章を簡潔にするために、なんらかの値のことをデータと表現し、なんらかの値がある状態をデータがあると表現することにする。（本来、データという用語に情報との関係性が含まれる場合もあるかもしれないが、それを否定するものではなく、本稿での便宜上の表現とする。）
これを踏まえて、機密情報をバックアップする際の機密性のことを考えてみる。バックアップした情報は、元の情報と同様に機密性を保護する必要があり、冒頭で紹介したとおり、バックアップ先での事故を想定することが必要である。このとき、ホットスタンバイのようなバックアップ環境であれば、元の情報がある場所と同程度の対策を講ずることができるだろうが、コールドスタンバイすらしない保管庫のように、保管しかしないような用途のバックアップでは、環境が異なり同程度の対策をしにくいことも考えられる。わかりやすい例としては、バックアップ媒体を保管するだけの場合である。
このときバックアップ媒体に書き込むデータの機密性を暗号で保護することが考えられるが、暗号化した情報は、鍵又はパスワードの総当たり試行で、元の情報に不正に復号（解読）することができる。（ http://yoshihiro.cocolog-nifty.com/postit/2006/09/post_e9f0.html ）このとき、総当たり試行の計算量が多大であれば現実的には復号（解読）できないとされるが、これはいわば計算量の多さで機密性の強度を保っていることになる。このため、計算処理性能や計算方式の改善などの技術革新があると、相対的に強度が弱まる。特に、バックアップ媒体のようなものが流出した場合には、長時間かけてじっくりと計算される危険性もある。
一方で、秘密分散という技術がある。この用語の定義や、逆にこの技術の呼称についてはいろいろあるが、ここでは、「情報を複数の断片に分散した際に、各断片には元の情報についての情報量がないように分散すること。そして、断片ごとに情報量がないが、それらの断片を組み合わせると、元の情報を復元することができること。」と定義することにする。
これは情報やデータを単に分割することとは異なる。その違いを説明するために、例として「２０１２」という４文字の情報を分割と秘密分散する違いを述べる。
分割の単純な例としては、「２０１２」を最初の２文字「２０」と後の２文字「１２」に分割することが考えられる。そのように分割した場合には、「２０」という断片から他方の断片である「１２」を計算処理などで導き出すことはできず、よって、元の情報が「２０１２」であったことを復元することはできない。しかし、４文字のうち２文字がわかってしまうため、情報量が半分にはなっているが、なくなってはいないので、先の定義による秘密分散とは言えないので、分割と表現した。
この例を秘密分散で考えると、たとえば、もとの「２０１２」を数字の２０１２と読み替えることにして、それを足し算の要素に分散するということが考えられる。具体例としては、２０１２を、９９９＋１０１３という足し算で置き換え、「０９９９」と「１０１３」という断片に分散するということだ。断片から元の情報を復元するには、断片を足し算すればよい。すなわち、９９９＋１０１３＝２０１２により、「２０１２」を復元できる。この場合も、先の分割と同様に、１つの断片である９９９から２０１２を復元することはできない。さらには、この場合には、「０９９９」には元の「２０１２」という情報の半分の情報量があるとは言えない。ただし、この足し算による分散の例では、９９９という断片から、元の数は９９９以上の値であるという情報量がある。これは、足し算で分散すると、元の数に対して、その断片は小さい数になるためである。それを改善する簡単な例としては、足した結果の下４桁だけを使うということが考えられる。具体例としては、２０１２を、７７７７と４２３５に分散させる。復元のときは、７７７７＋４２３５＝１２０１２となるので、その下４桁だけを使い「２０１２」を復元する。
足し算の要素に分散するというと、計算機に不向きに思えるかもしれないが、これを計算機に処理させるには、元の２０１２に対して、ランダムな４桁の数値を発生させ、その値を２０１２から引けばよい。先の例でいえば、９９９が発生したなら、２０１２－９９９＝１０１３により、相手となる断片を計算できる。７７７７が発生したなら、２０１２－７７７７＝マイナス５７６５となるので、これを１００００－５７６５＝４２３５とできる。
すなわち、元の数に対して、ランダムな数を発生させて、引き算することで、発生させたランダムな数と引き算の結果が、それぞれの断片となり、それらは、秘密分散の条件を満たすことになるのである。
ここでは４桁の数を例にしたが、任意の桁数に使えるようにするためには、これらを１桁の数の一連であるとすればよい。１桁の足し算をして、結果の下１桁だけを使うということだ。具体例を示すと、元が「２０１２」として、ランダムな数が「１３５７」だとすると、最初の桁から１桁ずつ順番に以下のように計算する。
１つ目の桁：２－１＝１ → そのまま １
２つ目の桁：０－３＝マイナス３ → １０－３＝７
３つ目の桁：１－５＝マイナス４ → １０－４＝６
４つ目の桁：２－７＝マイナス５ → １０－５＝５
したがって、「１３５７」という断片に対する、他方の断片は「１７６５」となる。検算してみると以下のとおり。
１つ目の桁：１＋１＝２ → そのまま ２
２つ目の桁：３＋７＝１０ → 下１桁だけ取って ０
３つ目の桁：５＋６＝１１ → 下１桁だけ取って １
４つ目の桁：７＋５＝１２ → 下１桁だけ取って ２
となり、「２０１２」が復元できる。
このようにすることで、何桁の数でも、簡単に分散させることができる。
また、ここでは２つの断片に分散する例を示したが、計算結果の断片に、また新たなランダムな数を使って、同じ計算をすると断片数を３つ以上に増やすことができ、それを復元するには、すべての断片を足し算していくだけでよいという特長がある。
ここでは数を表す文字列を例にしたが、電子情報はバイナリデータであるため、上記と同じ考え方の計算を、元の機密情報に対して、１ビット単位で、上記と同じ計算結果となる１ビットの足し算である排他的論理和という演算をすると、実用的に使える秘密分散の計算方式となる。（真の実用性としては、乱数発生の再現防止などの技術も併用する必要があるが、ここでは説明を省く。）
秘密分散という考え方を紹介したが、この計算方式にはいろいろな方式があり、ここではその一例を紹介したに過ぎず、計算方式の是非を問う意図はまったくない。
そのような秘密分散には、個々の断片に情報量がないことから、大きな特長がある。それは、分散した複数の断片のうち、どれか１つの断片が失われると、元の情報を復元することは不可能になるという特長である。
暗号で保護した機密情報が万が一、流出してしまった場合には、先述のとおり、流出時点での技術では計算量による強度で保護されるが、それが将来に渡って十分な強度を保つかは、未定となる。いつか破られてしまうかも知れない。
一方で、秘密分散した機密情報については、断片のひとつが流出した場合には、残りの断片のどれかひとつを自ら消去することで、流出した断片から元の機密情報が復元されることはなくなる。いうなれば、オフラインの情報に対して、遠隔で情報量の消去ができるようなものである。つまり、秘密分散は、情報量をなくすことで機密性の強度が保たれている。
空間的な分散を述べてきたが、時間的な分散に利用すると、より効果的である。機密情報を移送する場合に、秘密分散を行ない、１つ目の断片の移送が無事完了してから、次の断片の移送を行なうことで、移送途中の事故に備えることができる。最初の移送で事故があれば、それ用のペアとなる次の断片の移送開始前に破棄すればよいからである。秘密分散の処理は、またやりなおせばよい。この移送方法は、都内の某自治体から相談を受けて考案したものであるが、個人的にはすべての自治体、政府機関、企業にも機微情報の移送時に採用してもらいたい対策である。
もちろん、すべての断片が流出した場合には、不正な復元を防ぐことはできないので、情報流出のリスクを回避する対策ではないが、流出の予防策としては、先述のとおり簡単な技術であるがゆえ、導入する費用対効果に期待することができるはずだ。
また、最近になって著名なクラウドサービス事業者によるデータ消失という事故があった。それにどう備えるかを考えたとき、クラウドサービスでの事故も想定するなら、結局は重要な情報のバックアップは、クラウド事業者に対する機密保護まで考慮すると、クラウドを利用できずに社内に情報保管をするしかないと考えてしまうかもしれない。しかし、その解決策として、クラウド上の複数の異なる保管サービスに、秘密分散して情報を保管することが考えられる。（ただし、そのときには少なくとも４か所に保管する必要がある点について自問自答してください。笑）
さて、前置きで紙面を使いきってしまったが、そのような秘密分散などを想定した時、「情報量のないデータの流出は情報の流出になるか？」という考察のきっかけにしたい。もちろん、この文言には、「情報量」をどう定義するかとか、先に述べたとおり「データ」という表現は適切かとか、「流出」という語彙にそもそも出てはいけないものが出ることの意味があるだろうなど、文言としての欠陥があることは承知している。しかし、この問いの趣旨について、前置きとして説明できたのではないかと思う。この趣旨にあった用語や表現も探しながら、この考察をすることが有益ではないかと思う。
これらについて一定の割り切りでビジネスを推進する海外に対して、国内において、これらの課題と解決策の共有をすることで、これからのクラウド時代、ビッグデータ時代において、国内法規制等が国内企業を不利にさせないようにする必要がある。そのためには、この問いについては、技術的な知識を必要とするが、技術者以外にも理解しやすい説明をしながら、司法、立法、行政のそれぞれでも、認識を一にすることが重要である。
【著作権は佐藤氏に属します】
