はじめに
先日、スマートフォンアプリケーションのセキュリティに関するセミナーを聴講しました（2月8日追記。講演者からの依頼によりセミナーのサイトへのリンクをもうけました）。この際に、スマートフォンアプリケーションの脅威に対する共通認識がまだないという課題を改めて感じました。その課題を痛感できたという点で、セミナーは私にとっては有益でした。このため、当ブログではスマートフォンアプリケーションの話題をあまり取り上げていませんでしたが、今後は、とりあげようと思います。まずは、スマートフォンアプリケーションでは暗号化を必須とするべきかという話題です。この話題は、前記セミナーでもとりあげられていました。
暗号化の目的は何か
まず、暗号化の必要性を論じるためには、暗号化の目的を明確にする必要があります。前記セミナーでは、この目的が明確に示されていませんでした。一般的に、通信を暗号化する目的には、以下の2つの可能性があります。
- 第三者からのデータ盗聴を防ぐため
- 第三者だけでなく、アプリ利用者にもデータ通信の内容を見せないため
先のセミナーでは、質疑応答にて、SSLだと利用者には通信内容が見えてしまうので、GET/POSTの内容を見せないような暗号化が望ましいと説明していました。つまり、SSLではなく独自の暗号化ということでしょうが、そうすべき理由は明確に説明されませんでした。
利用者にも通信内容を見せない理由
利用者にも通信内容を見せたくない動機は、悪意の利用者を想定してのことです。この想定自体は妥当です。では、悪意の利用者のどの行為を防ぎたいのでしょうか。以下の二種類が考えられます。
- サーバーの脆弱性をついた攻撃
- ゲームなどで、正規のアプリでは困難なプレイを実現する不正なクライアントの作成
「隠すこと」による脆弱性対策は危険
通信内容を隠してしまえば攻撃もできなくなるだろうという発想は危険です。完全に隠し通せるならともかく、完全な隠蔽は困難であるからです。その理由は、スマートフォンアプリケーションの場合、暗号鍵を隠すことが困難であるからです。アプリケーションのリバースエンジニアリングが可能なので、鍵の保存方式を解析されれば、暗号を破ることができます。このため、アプリの難読化ということをするわけですが、あくまで「難読」であって、「不可読」ではないので、鍵を盗まれる可能性はあります。
このため、サーバー側の脆弱性対策については、Webアプリケーションと同様に「全ての通信内容は把握される」ことを前提として、脆弱性を元から断つことが必須です。
独自の暗号化が必要な場合
一方、ゲームなどのアプリケーションの場合、不正プレイを防止する等の目的で、通信内容を秘匿したいニーズがあります。この場合も、前述のように、通信方式がばれるリスクはあるわけですが、以下のように考えるとよいでしょう。
- 通信方式が解読された場合でも、利用者の個人情報などは漏洩しないよう実装する
- 通信方式が解読された場合に備えて、サーバー側ロジックにも不正プレイ対策を組み込む
- その上で、独自の暗号化とアプリの難読化を施す
独自暗号化のデメリット
一方、独自暗号化にはデメリットはないでしょうか。私は、独自暗号化にはデメリットもあると考えます。最近のスマートフォンアプリをめぐる話題として、プライバシー情報の不正送信というテーマがあります。このため、アプリ提供者には以下が求められるわけです。
- アプリの実現に必要最低限のパーミッションを用いる
- 取得およびサーバー送信するプライバシー情報を開示する
このため、通信内容を監査可能な状態に保つ（SSLのみで暗号化する）ということは、アプリ提供者が身を守る上でも有効だと考えます。上記二項は守った上で、「調べたければいつでもどうぞ」という状態にしておけば、提供側も堂々と構えておけばよいわけです。
一方、利用者当人にも読めない暗号化がしてあると、「本当はプライバシー情報も送信しているのではないか」という疑惑は（パーミッションを外す以外の方法では）ぬぐえません。
スマートフォンアプリにSSL暗号化が要求される本当の理由
先のセミナーでは、スマートフォンアプリが通信を暗号化すべき理由として、従来型携帯電話（フィーチャーフォン、俗に言うガラケー）と比べてWi-Fiでの利用があり得るので、盗聴のリスクが増すからだと説明されていました。この説明自体間違ってはいませんが、もう少し深い理由があると私は考えます。Webアプリケーションの世界では、SSL暗号化は「望ましい」条件であって必須とまではされていません。その理由は、SSLの使用に費用が掛かるためということもありますが、SSLを使っているかどうかは、ブラウザの錠前マークを見れば一目瞭然であるので、利用者が回線品質に不安があれば、SSL不使用の場合に自分の判断で利用を止めることができるからです。
一方、スマートフォンアプリケーションの場合は、アプリケーションがHTTP平文通信しているのか、HTTPSの暗号化通信を利用しているのかは、一般利用者には分かりません。
このため、今後スマートフォンアプリケーションでは、以下のように考えるとよいと思います。
- アプリケーションの場合SSL通信しているかどうか利用者には分からないため、通信路をSSL暗号化していない場合にはその旨を告知することが望ましい
- 告知せず平文通信している場合は、アプリケーションの脆弱性とみなすことを提案します
（公開情報のみを通信している場合を除く） - 前提として、公衆無線LANには信頼性の低いものがあり、スマートフォンから利用されてしまうリスクが現実的に存在するため
追記(2012/2/8)
twitterで @bulkneets さんからコメントを頂きました。徳丸さんの、平文で通信するiOSアプリの通信内容が改竄された結果として受信したレスポンスそのまま表示なりして、そのインジェクションされたコードから触れるAPIなりファイルなりが機密データだったら、そのアプリが扱ってる情報と関係なく危険なので公開情報のみ通信してるかどうかは関係ない(リンク)確かにその通りです。
改ざんされた場合、コードが実行できない場合でも、間違った情報が見えるという時点でセキュリティ上の問題が生じる可能性はありますね。
ということで、「公開情報のみを通信している場合を除く」という但し書きは、大ざっぱな免責条項として書いたものですが、正確ではありません。安全サイドに倒すならば、「平文通信の場合は常に告知せよ、そうでなければ脆弱性」というガイドラインがよいことになります。
まとめ
スマートフォンアプリケーションのセキュリティ全般の話題の後、スマートフォンアプリケーションでは暗号化に対する要求がWebアプリケーションよりも厳しくなる理由を説明しました。手元のTwitterアプリケーションなどを調べると、平文送信しているものもけっこう見かけます。それらが即脆弱だというほどの共通認識はできていませんが、今後の議論により、アプリの平文通信が脆弱性か否かや、脆弱性と言えるための条件等について、共通認識が得られればと希望します。
スマートフォンアプリケーションのセキュリティ強化策についての相談は、HASHコンサルティング株式会社まで。
「安全なWebアプリケーションの作り方」DRMフリーのPDFによる電子版もあります。
0 件のコメント:
コメントを投稿