UDIDにおけるセキュリティ＆プライバシー問題：デジタル・アイデンティティ技術最新動向（5）（1/2 ページ）
これまでの連載では「OAuth」と「OpenID Connect」について紹介してきましたが、今回は少し趣向を変えて、UDIDについてお話しします。
これまでの連載では、「OAuth」と「OpenID Connect」について紹介してきました。今回は少し趣向を変えて、UDIDについてお話ししようと思います。
UDID（Unique Device Identifier）とは、その名の通りデバイスに固有に割り振られた識別子のことで、具体的にはiPhone/iPadのデバイス識別子のことを指します。このUDIDは本来、米アップルが出荷したデバイスを識別するために割り振ったものです。
しかし、ガラケー時代に広まった、契約者固有番号や端末識別子を用いて認証する「かんたんログイン」方式を、UDIDを用いてそのままiOSアプリにも適用する事業者が増え、多くの問題を発生させてきました。今回は、こうしたUDIDに起因する問題について見ていこうと思います。
UDIDに起因する問題には、セキュリティ上のものとプライバシー上のものがあります。セキュリティ上の問題の中には、それ自体がプライバシー上の問題を引き起こすものもありますが、そのせいか、セキュリティの問題とプライバシーの問題が混同されているケースもまま見かけます。
そこで本稿では、2回に分けて、UDIDに起因するセキュリティの問題とプライバシーの問題をそれぞれ順に見ていくことにします。
「かんたんログイン」の仕組み
ガラケー時代のかんたんログイン
すでにご存知の方も多いと思いますが、まずはガラケー向けサービスで利用されていた「かんたんログイン」の仕組みを振り返ってみましょう。
ガラケーには、UDIDとよく似た「契約者固有ID」という識別子が存在します。携帯電話からのアクセスに付与されるこの識別子を信用し、パスワードなどを入力する手間なしにユーザーの認証を行うのが「かんたんログイン」です。
契約者固有IDは、キャリアの専用ネットワークを通じて携帯電話から送られるHTTPリクエストに、キャリア側がHTTPヘッダーを追加するという形で、サービス提供者のサーバに送信されます。
このHTTPヘッダは、キャリアが端末認証を行った結果として付与されます。キャリアの認証結果を信用することで、第三者が、このヘッダをユーザー認証のために使うことができました。
一方で、キャリアがそれぞれ独自の異なるHTTPヘッダフィールドを使っているため、ソフトバンク端末からのリクエストにドコモ端末を装ったHTTPヘッダを付与する、などの手法で、なりすましが発生するケースも指摘されてきました。このような脆弱性を生まないためには、適切にIP制限を行う必要があります。
つまり、ガラケー時代のかんたんログインは、キャリアの閉じたネットワークとキャリアの端末認証のセキュリティレベルに依存した形で実現されていました。
スマホ時代のかんたんログイン
iPhone/iPadでも「かんたんログイン」を実現するために、契約者固有IDの代替としてUDIDが利用されています（Androidの場合は「Android ID」という端末識別子が用いられます）。
ただし、Wi-Fi接続も可能なスマホでは、キャリアのネットワークに閉じていることを前提としたIP制限は行えません。また、UDIDはキャリアが端末認証を行った結果として付与されるわけでもないため、キャリアのセキュリティに依存するという前提も成り立ちません。そのため、多くのアプリ開発者が間違った形でかんたんログインを実装してしまい、簡単になりすましが可能になってしまっているケースが多く見られます。
以下に、UDIDを使ったかんたんログインの代表的な実装方法と思われるものをいくつか挙げてみます。
- UDIDそのものをHTTPS経由で送信する
- UDIDの（HMAC-SHA256などの）鍵付きハッシュ値を送信する
- UDIDをアプリ固有の暗号鍵で暗号化して送信する
それぞれ、その問題点を見ていきましょう。
ここが変だよ！ UDIDを使ったかんたんログイン実装例
UDIDそのものをHTTPS経由で送信する
UDIDをHTTP経由で平文で送るのは問題外として、「HTTPSで送信すれば安全だ」と考える人も少なからずいるようです。
確かにHTTPSを使えば、通信経路の途中で通信内容が改ざんされる恐れはなくなります。しかし、攻撃者がSSLプロキシを用意し、端末をそのプロキシ経由でネットワークに接続すれば、プロキシ上で通信の改ざんが可能になります。
実際「Charles Proxy」というシェアウェアを使えば、特に専門的な知識がなくても自分のPCにSSLプロキシを立てることができ、iPhoneから送信されるSSLの通信内容を比較的簡単に改ざんできてしまいます。
このような環境では、攻撃者が被害者のUDIDを知ってさえいれば、簡単に被害者になりすますことができてしまいます。そもそもUDIDは、それを利用するすべてのアプリに対して同じ値が返されるため、特定ユーザーのUDIDは広く知られていると考えるべきでしょう。
UDIDの（HMAC-SHA256などの）鍵付きハッシュ値を送信する
SHA1やSHA256などのハッシュ関数を用いてUDIDのハッシュ値を計算し、その値を送信するという実装が存在しますが、これは問題外です。ハッシュ値からUDIDそのものの値は計算できませんが、前述のように、元のハッシュ値が複数の事業者に知られているため、攻撃者が被害者のUDIDを得てそのハッシュ値を計算することは容易です。
一方で、単純なハッシュ関数を用いるのではなく、HMAC-SHA256などの鍵付きハッシュ関数を利用して、UDIDが公知でもアプリに埋め込まれた秘密鍵が漏えいしなければ大丈夫と考える方もいます。
しかしこの場合も、逆コンパイルなどで鍵が漏えいする危険性があります。ひとたび鍵が漏えいしてしまえば、たとえ鍵付きハッシュ関数を利用していてもなりすましを防ぐことはできません。
また、iPhone/iPadの「Jailbreak」により、端末のUDID自体を書き換える方法も存在します。端末自体のUDIDが書き換えられてしまうと、アプリは書き換えられた後のUDIDを元に鍵付きハッシュ値を計算してしまいます。従ってこの場合もなりすましを防ぐことができません。
UDIDをアプリ固有の暗号鍵で暗号化して送信する
これも鍵付きハッシュ関数同様、鍵が漏えいしたり、Jailbreakにより端末自体のUDIDが書き換えられたりする場合には無力です。またサーバ側の情報が鍵情報とともに漏えいした場合、攻撃者に元のUDIDを知られることになるため、ハッシュ値を用いる場合と比べてセキュリティ面でのリスクは増大するといえます。
Copyright © ITmedia, Inc. All Rights Reserved.