まだ曖昧な部分もあるので書くかどうか迷いはしたのだが、一定の結果には至ったので僕自身が持っている疑問の提示と皆さんへの問いかけという意味を込めて書き連ねてみる。

iPhoneアプリに「楽天銀行アプリ」というものがある。名前通り楽天銀行へログインし自身の取引結果や振り込みなどを行えるアプリだ。
僕自身も楽天銀行には口座を持っているので試してみたのだけど、「あれ？」と思わざるを得ない仕様があった。
簡単に説明すると次のような手順でこのアプリは使用する。

クイックログインの仕様

1. 起動するとまずログインメールアドレスとパスワードの入力を促される。これは通常のWEBサイトへログインする際と同じものだ。
2. 入力すると「クイックログイン」の設定画面へ遷移する。実は楽天銀行アプリではこのクイックログインの設定をしなければ使用できない。クイックログインではまずその画面のボタンを押して「ワンタイムパスワード」をメールで要求する。
3. 設定しているメールアドレスへワンタイムパスワードが届く。これは英数字4桁だ。これを先の画面にある「ワンタイムパスワード」の入力フィールドへ入力しクイックログイン設定を終わらせて初めてログイン状態となる。
4. 次回以降の起動時、このクイックログイン状態になる。クイックログインではログインメールアドレスの入力が省略されている。つまりすでにクイックログイン設定をした際に決定されたものが引き継がれているのだ。またパスワードだけを入力してログインすることになるのだが、パスワードはなんとオリジナルのパスワードの「先頭4桁」に強制的にされてしまう。

「あれ？」と思わないだろうか。クイックログインを行うとログインメールアドレスの入力が必要ないということは、どこに紐付けられるのだろうか。また銀行サイトということで僕などはわざわざランダムでそれなりの長さのパスワードを付けているのだが強制的に4桁にされてしまうのだ。
まず感じたのはログインメールアドレスをどこで保持しているかだ。ローカルかサーバー側か。またサーバー側だとすると端末の何と紐付けているのか。
また当然ながら、ガラケーならともかくiPhoneのようにソフトキーボードが充実した端末でわざわざパスワードを短くする理由が分からない。
特に前者に関して最初に思ったのは「これはUDIDなどの端末固有情報と紐付けてしまっているのではないか」ということだ。
この先の話では常に前提になるのだが、この 「UDIDなどの端末固有情報と紐付けてしまっているのではないか」というのは僕自身の推測でしかないことに注意して欲しい。

実地確認した事項

さて、ではということで実験を幾つか行ってみた。その内容を記載してみる。

• まず楽天銀行アプリはある端末でクイックログイン設定をしていると(していなくても)、他の端末では同様にクイックログインからの設定から始めなければならない。更にその端末でクイックログイン設定を進めると「他の端末で設定されている」旨のメッセージが表示される。それでも続けるとその端末でクイックログイン設定が完了できるが、同時に別の端末で行っていたクイックログイン設定は解除される。つまり端末認識をしており、常に一台でしか有効にならない。
• 一度クイックログインを行い、端末からアプリをアンインストールし再インストールするとクイックログインが解除される(ログインメールアドレスとパスワードを求める画面に戻る)。これについては後述する。

ここまでは基本的な仕様ということでよいだろう。次に上記を確認するために以下のようなテストを行ってみた。

• 楽天銀行アプリをインストールした後、UDIDを別の端末のものに偽装した上でクイックログインを設定。問題無く利用できることを確認した上で偽装を解除すると、クイックログイン状態は解除される。これには二つの考え方があり得る。つまりUDIDは全く関係ないか、あるいはUDID以外の端末固有情報も利用しているかだ。
• 上記の場合、偽装元のUDIDを持つ端末でアプリを起動してもクイックログイン状態にはならない。これはやはり上記と同じことが考えられる。

これだけではまだ判別が付かない。そこで以下のテストを追加した。

• まずはパケットをキャプチャしたかったがSSL接続であったので相手サーバー名までしか分からず
• 楽天銀行アプリがインストールされているフォルダ(例えば/private/var/mobile/Application/(楽天銀行アプリのguid)/)以下のディレクトリで、楽天銀行アプリをインストールして起動した直後とクイックログインを設定した直後で比較した。結果、クイックログイン設定によりとあるプロパティリストファイル(仮に名称からsapiファイルとしておく)が追加されることが分かった。それ以外に変更点は無いように見える。しかしこのsapiファイルの中身ほぼ空の単純なプロパティリストで、例えば認証情報のようなものを保持しているようには見えない。
• このsapiファイルをバックアップしておく。次に楽天アプリを一度アンインストールして再インストール、直後にやはりすべてバックアップしておく。クイックログイン設定をして正常に動作することを確認して終了。次に/private/var/mobile/Application/(楽天銀行アプリのguid)/以下を全て削除。先にバックアップした楽天銀行アプリ全体のバックアップに差し替え、更にsapiファイルも書き戻す(ここ重要)。そうして起動すると問題無くクイックログイン状態となった。
• 上記でsapiファイルを書き戻さない場合は(当然ながら)初期状態に戻った。つまり楽天銀行アプリはまずsapiファイルがあるかどうかでクイックログイン設定されたかどうかまずは判別しているのだろうと推測。
• ほぼ確認はしたが更にインストールされた直後に/private/var/mobile/Application/(楽天銀行アプリのguid)/以下をroot:adminへ権限変更。通常アプリはmobileユーザー権限で動作するのでこれでローカルは読み込みさえできなくなっているはず。クイックログイン設定を行い正常動作を確認した後終了。権限をmobile:mobileへ戻し起動するとクイックログイン状態のままであった。因みに戻すのを忘れて起動するとクイックログイン状態は解除されている。これは恐らくsapiファイルが読み込めないので初期状態と判別れるのだろうと推測。因みにこの状態でクイックログイン設定を進めても、一度は正常に完了するが、一度再起動すると初期状態に戻ってしまう。これもsapiファイルが書き込めないためだろうと推測。

以上から僕自身は

• ローカルには何も秘密情報はおろか何もクイックログイン設定時には保存されない。必然的にその後も使用される何かの情報は存在しない。
• 楽天銀行アプリは起動時に必ずサーバーへアクセスして、それから初期状態かクイックログイン状態かのいずれかを表示する。つまりサーバーに対して何らかの確認を行っていることはほぼ間違いない。
• UDIDを変更するとクイックログイン状態が解除されたことからクイックログインとの紐付けに何らか使用していることは間違いない。但しUDIDだけが関わっている訳でもないらしい。
• 少なくともパスワードが4桁に制限されてしまうこと、および確認はできなかったがもし仮にUDIDなどの端末固有情報でログインメールアドレスと紐付けしているのであれば偽装の危険性はないのか。

と結論づけるに至った。

楽天CERTとのやり取り

そこで以下のようなメールを楽天CERTに対し送ってみた。

楽天CERT ご担当者殿

お世話になっております。

御社グループである楽天銀行殿で提供されている「楽天銀行アプリ (http://www.rakuten-bank.co.jp/benefit/mobile/iphoneapp.html)」のセキュリティについてご質問させてください。

楽天銀行殿WEBサイトの説明によれば、このアプリを使用するにはクイックログインの利用が必須となっています。

私も楽天銀行に口座を持っていますので実際にも利用させて頂きましたが、ワンタイムパスワードをメールで要求し、初回のみログイン・メールアドレスおよびパスワードを入力した後、ワンタイムパスワードを入力して初めてログイン可能となります。

しかし次回以降はクイックログインとなってしまい、ログイン・メールアドレスの入力は省略され、更にパスワードの入力は先頭4桁に強制的に制限されてしまいます。

以上を前提にご質問させてください。

1. 次回以降のログイン・メールアドレスはどこに格納され、どのような仕組みで実際の口座アカウントと紐付けされていますか

2. 1に関して、実はiPhone内部を精査しましたが少なくともローカル環境にはログイン・メールアドレスは格納されていないと考えています。とすると考えられるのは何らかの端末固有情報を送信して、初回登録時の情報との紐付けでログイン・メールアドレスを決定しているのではないかという疑いです。

この端末固有情報として、iPhoneのUDIDを利用していないでしょうか。

iPhoneのUDIDの利用については恐らくご存じの通り危険性が指摘されています。

参考:

http://jp.techcrunch.com/archives/20101228suit-against-apple-alleges-privacy-breaches-by-apps/

http://togetter.com/li/28715

http://takagi-hiromitsu.jp/diary/20090802.html

UDIDは決してユーザー個人の秘密情報ではなくまた簡単に偽装可能であることもよく知られています。

もしそうであればこうした機密性の高いアプリケーションでの利用は改修されるべきではないでしょうか。

3. 次回以降パスワード入力が4桁に強制的に制限されるのは何故ですか。iPhoneは通常の携帯電話より操作性に優れたソフトウェアキーボードを備えています。利用者の利便性のためと考えても理由がよくわかりません。

また長いパスワードを利用してセキュリティを確保したいユーザーの意向が無視されている点も気になります。

なお別途4桁のパスコードによるスクリーンロックを任意でかけられることも存じていますが、そもそもデフォルトで強制される4桁パスワードで満足するユーザーならわざわざ別にスクリーンロックをかけるとは思えません。仮にかけたとしても通常のユーザーであれば双方には同一のパスワードをかけようとすることでしょう。

以上です。

社としてのご見解をお聞かせ下さい。

またこのメールのやり取りについては、内容如何によりましてはネットにて概要を公開させて頂く場合がございます。どうぞご了承下さい。

以上お忙しい中恐縮ですが、どうぞよろしくお願いいたします。

何度かやり取りはあったのだが、先方の返答としては以下の通りとなった。

• パスワード長の問題に関しては改善したい。
• ログインメールアドレスと口座の紐付けについては攻撃者へのヒントとなり、当方にメリットはなくリスクにしかならないので仕様の開示はできない。
• 仮に開示したとしても即時に攻撃可能になるとは考えていない。
• UDID については本件サービス企画時より単体使用時の脆弱性を十分に認識し、必要なセキュリティ措置を講じている。このため例えば UDID を任意のものに変更することで、認証を通過し第三者になりすますことはできない。なおリリースに際しては第三者機関による安全性の検査も実施している。
• UDIDはログインメールアドレスとの紐付けには使用していない。ログインとは別の要件で使用している。改竄されることも折込済みでとあるチェックで利用しているにすぎない。
• (ローカルに情報が保存されている形跡がないことから端末固有情報で紐付けしているのではとの指摘に対して)詳細は答えられないがそちらで確認された点は事実とは異なる。
• これ以上の具体的な情報開示は出来ず納得頂くのは難しいかとは思うが心配されている不適切な実装は行われていない。

とのことであった。

何が問題となるか

まず強調しておきたいのは、仮にログインメールアドレスとの紐付けを行っていたのだとしても、それが楽天銀行アプリの直近の脆弱性にはならないという点だ。長さに問題があり改善されるべきだとしても、仮に端末偽装に成功したとしてもパスワード入力という壁が(薄いながらも)存在している限り、即脆弱とは言えまい。ここに議論はない。

しかしながら、まず1点目として「秘密主義とディスクロージャー」の問題がある。
回答にもあったとおり、「詳細は言えないが安全だ」というのが先方の主張となる。何から何まで開示しろとは思わないが、しかし僕自身は楽天銀行の顧客である。それが求めた「安全性の根拠」に対して 「信用しろ」の一言はさすがに無いのではないかと思う。
詳細は出せないにしても、もう少し一般的な説明は存在しないのか。簡単に言えば、もし先方の言うとおり「開示したとしても即攻撃は不可能」なのであれば、具体性を省いた形で幾らでも論理的な説明は可能なはず、逆に言えばそれさえできないのだとしたらやはり何らか仕様を隠さなければ危険にさらされる何かがあるのではないかと勘ぐってしまうのだ。
この感覚には既視感があり、例えば電波チェッカーの際のやり取りで感じたのとほぼ同じことを感じる。

次にUDIDその他端末固有情報との関係性である。上記の通り、完全にこちらの調査と先方の言い分は真っ向から対立している。というより矛盾している。どちらかが正しいならどちらかが完全に間違っている状況かと思う。
果たして僕の調査結果が間違っているか、その結果からの推測が誤っているのだろうか。それとも先方が嘘をついているかあるいは現場からの報告を誤認しているのか。果たしてどちらだろうか。
僕自身は現時点でも、はっきりした調査が完全に行えていないのでまだ完全な結論には達せていない。状況証拠的には十分に正当性を主張できるとは思うが、 完全に仕様を明らかにするには至っていないのでまだあいまいなままだ。
(実は「とある」情報がUDIDを補完しているのではないかと推測しているのだがそのテスト方法が見つけられていない)
しかし個人的には上記二点の不明瞭さからはこの楽天銀行アプリを使用するのは止めようと思っている。これは単純に仕様の精査が「疑わしく」また自身の感触からは先方の言い分を信用できないためだ。信用できないアプリを使用しなくてはならない理由は無い。但し、あくまで個人的な感想であるということは強調しておきたいと思う。

最後に、果たして仮に「ログインIDと端末情報の紐付け」はセキュリティ上どう捉えるべきだろうか。
楽天銀行アプリからは離れて、仮にそうした仕様のアプリがある場合、それは脆弱であると言うべきだろうか。
はっきりしておかないといけないのは、これはよく問題になるような「UDIDなどの端末固有情報のみで」認証を行っている訳ではないということだ。あくまでユーザーIDの保持だけである。
しかし一方では、そうであればWEBアプリでユーザーIDの入力を省略するためにCookieで保持するように、サーバーサイドで発行した十分にランダムで推測不能な文字列を発行しアプリ側で保持すればよいだけだ。UDIDのような「秘密情報でない」情報を用いる積極的な理由は存在しない。
脆弱かどうかと言うのは言葉の定義からして難しいが、しかしよりよい方法が広く知られているにも関わらずそれを用いないのは好ましくないか、近い将来いずれかの時点で脆弱だったと見なされる可能性があるということだ。
例えばこの2011年の時点で「セッションを単にパスワードから導いたハッシュ値にしているWEBシステム」があればほぼ脆弱だと判定されると思うが、多くの人がそうは感じない時代もかつてあった。

また重要なのはUDIDのような容易に端末を特定し偽装が可能であり秘密ではない情報をアプリで気楽に用いるべきではない。
iPhone SDKでは審査基準として「ユーザーアカウントに紐付けてはならない」というポリシーがあるようだが、しかし如何にアップルの審査であったとしても、端末固有情報をどのように使用しているかまではチェックできていないだろう。
ましてやAndroidマーケットにおいては無法地帯であると言ってよいだろう。
だとすれば後は頼れるのは開発者個人個人の自覚でしかない。よってこうした問題はフォーカスされ、開発者同士で共有されるべき問題だと思う。

さて、ここでようやく皆さんに質問だ。果たして皆さんはこの問題をどう捉えるだろうか。
正直言って、僕自身も一定の見解はあるものの先に述べたように最終的な裏付けがないのでかなり悩みながらこれを書いている。しかし皆さんはどのような感想・意見を持たれるだろうか。またこうした問題(または疑念)はこれだけとは思わない。
ぜひ僕自身にも見解を教えて欲しいと思う。

追記

今更知ったのだけど、クイックログインってそもそもケータイ向けに以前から提供されていた機能のiPhoneへの適用なのですね。
ケータイではこの端末認識を固有識別ID(サブスクライバーID)で行っているということだが、ではiPhoneでは何を用いているのか・・？

追記 (2011/01/23)

続きを書きました。