MagoPicまでの長い道のり その二

September 20th, 2011

やはりないもんは自分で作るしかありません。Google+が全部解決してくれそうと思いつつも、とりあえず親孝行と思って作ることにしました。

最低限以下の点をカバーしようと思いました。

  • 簡単手間なし
    • 自動でアップロード
    • 自動でダウンロード
    • 自動で更新通知
    • ユーザー登録(ID/Password)完全不要
  • プライバシー
    • データはクラウドに置くがPGPのような方式でEnd-to-Endの暗号化

End-To-Endの暗号化やユーザー登録なしでのアカウント管理は従来のブラウザをインターフェースとしたクラウドサービスでは出来ません。厳密に言うとJavaAppletやActiveXやJavaScript(非現実的)を使えばEnd-to-Endでのデータの暗号化/復号化はできますが、パフォーマンスや可搬性やトレンドから考えて良策ではないと判断しました。ただ、Native Clientはありです。それを除いてはやはりスマートフォンのアプリという選択肢が有力という結論に至りました。ちなみに、ユーザー登録なしでのアカウント管理というのは多くの方にはあまり馴染みがないかもしれませんが、実はNintendo DSはNintendo Wi-Fi Connectionにおいて2005年の時点で既に実現していたりします。

調べたところ、AndroidのJava(CipherInputStream)、iOSのSDK(CCCrypt)いずれも標準でRSA(RSA1024のDER base64bits)とAES32を使えることが分かりました。サーバー側は基本的にkey serverとしての役割だけでよくて、クライアントで暗号化されたデータのリレーできればいいと思っていたのですが、実装しているうちにサーバーからクライアントに対して公開鍵で署名暗号化したメッセージを送れたらもっとセキュアなネットワークになるなぁと思い、サーバー側でも暗号化をサポートしました。これもGAEに標準で入っているpycryptで一発でした。

次は、ユーザーIDというかキーペアの生成に使うシードをどうするかです。iOSはUDIDやMACを組み合わせればデバイス固有のIDはほぼ確実に取得出来そうな感触でしたが、Androidではノーブランドの機種などもたくさんあり、物によっては再起動するごとにMACアドレスが変わるだとか、どれも同じデバイスIDを持っていたりだとかかなりのカオスっぷりだったので、諦めていろんなセンサーの情報等を寄せ集めたシードから乱数を生成するようにしました。

キーペアの生成と暗号複合、及びクラウドを経由した鍵交換のメカニズムが実装出来ました。さぁ、次はどうやってデバイス間で共有関係を結ぶかです。DSでいうフレンドコードの交換です。いくつか考えて、実際に試しました。

  • 実際にユーザー同士がFace-to-Faceで会える場合
    • Bumpでスマホ同士をぶつけるだけ (試した。基本うまく動く。3Gの載っていない端末では微妙)
    • QRコードなどをカメラでキャプチャ (試した。動くけどダサい)
    • NFC (試していない。対応機種がまだ少ない)
  • 遠隔地のユーザーと共有関係を結びたい場合
    • サーバー経由でメールで公開鍵のURLを送る (問題無し。とてもうまく動く。)
    • フレンドコードのような物を生成し、電話などで口頭で伝える(基本的に技術的にはメールと同じ)

これで、完全に暗号化されたネットワークで自由に静的なデータをやりとりすることが出来るようになりました。ただ、実際のユースケースを考えるとまだ足りないところがあり、下記の機能を実装しました。

  • 秘密鍵が漏洩した場合に、キーを更新して再度暗号化する仕組み (すべてのデータを再度クラウドにアップロードする必要があり。これは非現実的でありシステムの致命的な欠陥)
  • 一つの端末上に複数のアカウント(キーペア)を保有できる仕組み
  • アカウント(キーペア)をデバイス間で引越しさせる仕組み

ここまで実装して気づきました、「俺は家族と写真やビデオを共有したかったんだ」、と。

この仕組みは、めちゃめちゃセキュアで企業が秘密文書のやりとりに使っても問題ないほどの代物なのですが、大量のメディアデータを同時閲覧可能な形でやりとりするには様々な問題を含んでいます。

  • データ転送量、ストレージ消費が半端ない
    • サーバー側でのデータ操作が出来ないため、写真で言うと最大サイズのデータをやりとりして受信した側で行う必要がある(クライアントに大きなストレージが必要)
    • アップロードする際に、サムネイル、閲覧用、オリジナル、とあらかじめ想定した用途の画像を生成し、暗号化した上でアップロードする(データ転送量がかさむ)
    • ビデオのストリーミング再生が出来ない!!サーバーでのトランスコードも出来ない!!(デコーダーに手を加える必要がある。多分SDKの上ではむり。)
  • CPU負荷が高すぎる
    • ストレージを節約するためにOn Demandでデータをストリームするようにすると、その都度復号にかかるレイテンシとCPU消費量がバカにならない
  • Webブラウザ上で見れない
    • なんだかんだいってでかい画面で見たい。暗号化されたデータはブラウザで表示することが出来ないので、馴染みのあるWebインターフェースは作れん。(Native Clientが普及したら作るで)

CPU負荷、Webブラウザ上で見れないというのは時期尚早なだけで時間が解決してくれると思いましたが、データ転送量、ストレージ消費量に関しての最適解は(特にこの様なプライベートなネットワークの場合には)やはりクラウドを使わずにピュアP2Pでやることに帰結すると考えると、現実的な安定性とパフォーマンスを得るためには試行錯誤に相等の時間がかかりそうだと思いました。また、技術的な点ではありませんが、ここまで閉じたネットワークではバイラル効果がほとんど期待できず、サービスとしての継続は困難であると判断しました。

よって、ここまでのコードはすべてブランチを切ってさようならです。これらのコードはもう少し時代が追いついてきたら帰ってくることでしょう。

家族で簡単に安心して使えるスマホ世代の写真共有サービスMagoPic水が低き方へ流れるかのごとくユーザーの今の状況をより意識してよりフレンドリーなサービスを目指して方向転換していくのです。

つづく

 

4 Responses to “MagoPicまでの長い道のり その二”

  1. Shinya Yamada says:

    思った通り、おじいちゃん孝行のサービスだったのですね-(^_^)
    ところで、スマフォで3G対応でない機種ってあるの?ちょっと疑問なんだけど・・・。

    • exilis says:

      なんとびっくり!ご無沙汰しております!スマートフォンと呼ばれるものはいずれもモバイル回線を持っていると思いますが、iPod TouchやGalaxy Player、iPadのWiFi only版やAndroidタブレットのようにモバイル回線につながっていないデバイスの普及台数も沢山あります。

      • Shinya Yamada says:

        なるほど、スマフォではなくて、高機能携帯端末ということですねー。
        ところで、仕事の方はいかがですか?こちらはなかなか楽しくなりそうです。会社は名古屋ですが、横浜に週二日ぐらい行くことになると思っています。日本に来ることがあったら、連絡ください!

        • exilis says:

          そうです~。正確ではないですがスマホと言っておいた方がキャッチーかなと思いまして。仕事はボチボチですねぇ。山田さんは楽しそうでなによりです!日本へ帰るときにはご連絡します!

RSS feed for comments on this post. And trackBack URL.

Leave a Reply

*