石橋秀仁(zerobase)書き散らす

まじめなブログは別にあります→ja.ishibashihideto.net

アプリ固有秘密鍵公開鍵ペア

Open ID/OAuth プロバイダー (IdP) がユーザー毎アプリ毎の秘密鍵・公開鍵ペアを生成してくれたら、アプリ側のデータベースでは「アプリ側でも復号化できないデータ暗号化」で個人情報を保護できるんだが。

※ここでいう「アプリ」は RP (Relying Party) のこと。

ユーザーがユーザー・エージェント(ブラウザやスマホアプリなど)の上でデータを復号化して利用する方式。つまりユーザーの「手元」以外ではデータが暗号化される。

ユーザー自身のみアクセスできればよい「ユーザー固有データ」については、こういう方式で保護しておくと安全性が増す。

シングル・ユーザーでスタンダローンなアプリで特に有効だと思う。つまり MBaaS 系(Parse.comなど)をイメージしてる。あとは「もし iCloud がアプリ・プラットフォームになったら」的なイメージ。

  • サイバーアタックや流出事故に強くなる。
  • ユーザーがアプリを信頼する必要性が、少し減る。
  • データ・オーナーシップ(所有権)、ポータビリティ(可搬性)についても、ユーザーのほうがアプリ側よりも強いコントロールを持つ。エンパワーメント。

ちなみに「ユーザー間」のインタラクションがあるようなデータは暗号化できない。そこはID匿名化などの手法を組み合わせたい。IDやキーや集計用情報などのメタデータだけは平文で用意しておくなど。

情報アーキテクトとしては、こういうのを単なる技術だけではなくデザインとしてちゃんと構想したい。ユーザーにとって、これまでより難しくないか、より易しくなる。そのうえで安全性が増す。アプリを信頼する必要性が、少し減る。

(personal dataの考慮:access control (to whom?)軸と、topology (where?)軸で、平文か暗号か?という設計フレームワーク