Sixto Ortiz Jr.
How secure Is RFID?
Computer(IEEE CS), Vol.39, No.7, pp.17--19, July 2006.
RFIDは，そう遠くないうちにパスポートやクレジットカード，空港の荷物追跡や病院の患者用バッジなどの社会基盤でも使用されるようになるだろう．
# え，まじですか? クレジットカードや病院の患者識別用バッジは嫌なんですけど...
一方で、研究者はRFIDの潜在的なセキュリティ問題を懸念している．主な懸念は以下の2つである．
- 悪者が，RFID内のデータを書き換える(改ざん)
- 悪者が，RFID内のデータを盗み取る(盗聴) ... 品物の値段やカード所有者の個人情報等が第三者によって無断に収集される恐れあり
で、現状の見方が立場によって大きく異なっている
1. 懸念派 - 「状況は，あきれるほど悪い」とP.G.Neumann
2. 懐疑派 - 「そんなこと(想定されている脅威)は，まず起こりえない」とDan Mullen
懐疑派は、こういう．
"彼らは，どんな技術に対しても常に「より安全にしなければいけない」"と言うのさ．と
RFIDにおいてすでに想定されている、セキュリティ上の脅威 (若干の意訳とコメント入り)
■ DoS攻撃
- FHSS(frequency-hopping spread-spectrum方式で通信を行うRFIDに対して，DoS攻撃が可能
FHSSは干渉回避と盗聴防止に有効な通信技術だが、これを逆手に取り，全spectrumに渡って第三者が無意味な信号を発信する「RF jamming」によってDoS攻撃が可能．もちろん，この攻撃を行うためには、jamming信号を出し続ける必要がある．しかし、それが実行可能であれば、それによりRFIDはまったく機能しなくなる．RFIDが生命に関わることに使われていたとしたら、...大パニックである．
■ ウィルスの媒介
RFID(書き換え可能なRFID)を使って，ウィルス/トロイの木馬/悪意のあるコードを拡散可能である．ようするにRFIDがそういったマルウェア(malware)のコードを媒介するということであり、RFID自体がウィルスになるのではないが、そういう風に見る人もいるようだ．
1. ウィルスを作成し，そのコードをRFIDに埋め込む
2. リーダーがそのRFIDからデータ(ウィルスコード)を読み，アプリケーションに送る
3. アプリケーションはそのデータを処理する
4. アプリケーションの脆弱性を突く/システムのBuffer overflowを起こす/他のback-endシステムのsecurity holeを突く などの方法でウィルスがback-endシステムや計算機等で稼働し始める
# 問題は，RFIDから読み取ったデータを，アプリケーションやOS(?)がどう処理するかだな
RFID内に格納されるデータにproof-of-concept codeとしてSQLの脆弱性に関するデータを埋め込み，実際にback-endシステムで悪意のあるコードが実行されるデモを実施した研究者がいる．一方で、RFIDに格納できるデータ量は格段に小さいので問題にならないという懐疑派もいるらしいが、悪意のあるコードもコード量の小さいものは多数存在する．SQL injectionのcodeなら，単語数個分である．そして、もしデータベースがウィルスに感染したとしたら，ウィルスはデータベース内のデータを改ざんし，そしてその改ざんされたデータを元にさらに新たなRFIDが多数生成されるとしたら... その感染はものすごい勢いで拡散していくことになる．
■ タグの書き換え(改ざん)
比較的安価なRFIDタグは，正規の装備さえもっていれば誰でもデータを読み，そして書きかえることができる．そして、そういった装備は時間とともに安価になっていく．ということは...
RFDumpというアプリケーションがあるらしい．これは携帯端末上で動作させることで，RFIDのデータを読み書き可能にするソフトであり、こういったソフトはその意図はさておき、存在し続け、かつ誰でも利用できる状況になりがちであるということを認識することが大事であろう．とにかく「現状はそういう状況なのだ」という認識をもつことがセキュリティ対策の第一歩
● 車の盗難
最近の車はimmobilizer(イモビライザー)が付いており，RFIDなくしてエンジンが始動しないようになっている．それはchallenge & responseによって，所有者のRFIDと車との承認を行っている．しかし、もし，車とRFID間の通信を盗聴できたとしたら...，盗聴データから暗号化鍵が解析され，所有者がもつRFIDとまったく同一のクローンRFIDを作成することは簡単にできるだろう．そして、そのchallenge & responseもそれほど強力な仕組みでなければ，Brute-force攻撃でも看破可能であろう．また，多数のchallengeとresponseの組を盗聴によって記録し，そのデータを駐車場等で無線に乗せて流布することで，駐車場に止まっている車の鍵が偶然開いてしまうかもしれない．そうなると、車窃盗天国のできあがることになる．
● RFIDタグのクローン生成
データを書き換え可能なRFIDは，ビルの入退室管理などで多数使われている．そういったRFIDでは，先ほどの車の盗難と同様の手法で，正規のRFIDのクローンを作ることは容易．データを盗聴し，暗号化鍵を解析できれば，あとは正規のRFIDになりすますことのできるクローンRFIDタグの生成は容易! だとすると、ビルの入退室管理なんて...
■ 産業界の反応
すでに多数のセキュリティ機能が実装されているんだよ．だから大丈夫!
1) 盗聴を不可能にする暗号化処理が実装されている
しかし、暗号化処理の実装はRFIDのコスト上昇を招く．また製品の追跡等の目的でRFIDが使用されている場合，暗号化なんて使われない．なぜなら、そういったRFIDには，個人情報が格納されるわけではないから...でもね〜
2) 書き込み可能領域をユーザがロックできる機能
セキュリティ関係のシステムではよくある話だが、機能があっても使われない．なぜならば、1. 存在を知らない or 2. 面倒な作業を増やしたくないからである．まさにSecurity and Usability
3) 記憶容量が小さいから...
Automatic Identification and Mobilityの人曰く、
- もっとも小さなウィルスでもRFIDには格納できない
- RFIDは，その上でcodeを実行しない．単にデータを保持するだけだ
- RFID内のデータは，読み取り時に改ざんされているかどうかをチェックをする
- セキュリティの研究をしている人達の環境では，そういった脆弱性があるかもしれないが，商用製品ではそういった脆弱性はないし，そういった脅威は実際に機能しないよ
こういった主張に説得力がないのは、前述の通りであろう．
それに，万が一そうでないにしても，crackerはRFIDの内部情報に精通していなければそういった攻撃は実現できないはず．リーダーがどのように機能し，back-endのシステムがどうやってRFIDのアプリケーションと処理を連携しているかを知らないことには，悪意のあるプログラムを作成できないはず．
これはごもっともな話である．が、そういって実装の詳細を隠してきたシステムでもセキュリティホールは見つかる．その事実が、上の主張の無意味さを示していると言えるだろう．
セキュリティ研究者曰く、そういうならば，商用製品にて研究者に攻撃実験をさせるべきだ．少なくとも他の分野はすでにそうしている．なぜRFIDはそういうことをしないのだろうか?
なんにせよ、研究者と製品開発者は，RFIDをより安全にするためにもっと協力できるはずだ
いい技術だと思うのなら、すでに想定されている脅威に対しては、試験をし、脅威の存在確認と、必要であれば、なんらかの対策を早いうちに打つべきである事に疑問の余地はないだろう．
なんて書いていたら、タイムリーに電子パスポートのニュースが出ていました．
米国ビザの免除対象国24カ国が電子パスポート導入へ (ITPro)
RFIDパスポートが本格始動--米国ビザ免除対象24カ国が発行 (CNET Japan)
非接触ICチップ入り、つまりRFIDタグ入りのパスポートにする事で、ID盗難や偽造が防げるようになるそうです．が、上の記事を読んでいると、そうとは言い切れない面もあるかなと思ったり．また、Bruce Schneier氏も述べているようにプライバシー問題があると同時に、これによって偽造の可能性は余計に高まったと言えなくもないのでは? と考える．偽造が防げるのではなく、場合によっては簡単になる可能性も否定できないのでは? とも思ったり．
しかし思うのは、なんで「非接触」でないといけないんだ? と疑問に思う．よほど、接触式の方が勝手にデータが他の機器とやり取りさない分セキュリティが高く、ユーザにとっても情報のやり取りが行為と結びついていてわかりやすいと思うし、パスポートをアルミホイルにつつんで持ち歩かなくてもいいから、扱いも楽だと思うのですが、みなさんはどうお考えでしょうか?
auブランドの携帯電話で、ふたたび一般開発者によるJavaアプリが動かせるようになるそうです．対応端末は来年春に発表されるそうです
au携帯電話においてJava™で作成されたオープンアプリがご利用可能に - KDDIの発表
よく見てみると、BREW上でJavaアプリを再生する「オープンアプリプレイヤー」というJava動作環境が動作し、その上で勝手アプリを動かせるようにするそうです．Javaの仕様は、基本がMIDP2.0だそうです．なんにせよ、これによって色々なゲームアプリがauの携帯向けに開発されるようになり、活気づくのではないでしょうか? というか、auとしても、携帯ゲームの市場は無視できなくなったということだと推測する．
ということで、いろいろなニュースソースからざっと見てみると
au端末でJavaアプリが動く -- 来春発表の端末から - ITmedia
- Javaアプリケーションの再生機能 「オープンアプリプレイヤー」を来春以降発表の端末に搭載
- オープンアプリプレイヤーは、MIDP2.0に準拠したJavaアプリプレイヤーで、BREWのミドルウェアとして提供
- EZfactoryにてアプリケーション作成ガイドを提供
- 作成したJavaアプリは審査不要．自由に公開可能
au、来春にJavaアプリが楽しめる「オープンアプリ」導入へ
- 既存の端末は、オープンアプリ利用不可能
- 仕様はMIDP2.0準拠で、au独自の仕様は採用されない．
- Jarファイルは最大300KB、Jadファイルは最大6KB
- Java VMの開発元は、アプリックスで「JBlend」
独自仕様の採用がないのは残念ですが、なんにせよ、来春発表される端末に期待しよう
追記:
jig.jpの方が、仕様の詳細等についてCNet Japanの記事で語っている．で、記事の中にある表を見て思ったのだが、ソフトバンクモバイルのS!アプリ3Gは、クリアキーと発話キーにバツがついているのだが、これは一体どういう意味だろう．それらのキーもアプリで使用することができるという意味だろうか?...
携帯アプリを作成する上で、アプリの軽量化(バイトコードの量をより小さくする)と高速化を実現するためのTipsをまとめたWebページがあったので情報として残しておく
Vアプリを作ろう - http://potter.s5.xrea.com/vappli/950.html
無論、こういった技術は、ソースコードの可読性やバグを生む可能性を増大させるので、一長一短ではあります．こういった意味で、組み込み系プログラムは、通常の計算機での(富豪的)プログラムとは異なった配慮が必要だということです．
とはいえ、最近の携帯電話は、そこそこのスペックを持っているので、言われるほど注意を払わなくても、そこそこの速度で動作してしまう可能性もなきにしもあらず．