戻る

このページは以下URLのキャッシュです
http://japanese.engadget.com/2016/09/21/felica-hce-f/


海外の格安スマホでもFeliCaが利用可能になる? 「HCE-F」の正体を探る:モバイル決済最前線 - Engadget Japanese


ついにiPhoneがFeliCa対応となり、10月にはサービスが開始される予定だ。

これだけでも「おサイフケータイ」ユーザーにとってはうれしい話なのだが、実は世界中のAndroidスマホのほとんどがFeliCa対応可能になるかもしれないという。

キーワードは「HCE-F」という規格だ。

「HCE(Host Card Emulation)」とは、スマートフォンなどにおいて通常セキュアエレメント(Secure Element:SE)を通じて行われる「カードエミュレーション(Card Emulation:CE)」という処理を、ホストCPU、つまりモバイルOSが動作するシステム上で行う仕組みのことだ。

その最大の利点は、通常のSEを用いたCEが「SE」という専用ハードウェアを要求するのに対し、HCEではNFC(Near Field Communication)の機能を内蔵しているスマートフォンであれば、特別なハードウェアなしにCEの仕組みを利用できることにある。Googleの決済サービス「Android Pay」はこのHCEの仕組みを応用したもので、Android 4.4以上のOSの動作するスマートフォンであれば基本的にどれでもサービスが利用できる。

話題の「HCE(HCE-F)」とは

では、HCE-Fとは何だろうか? 当初、Androidに実装されたHCEでは、海外で一般的な「NFC-A」「NFC-B」仕様に準拠しており、主に日本で広く利用されているFeliCaのインターフェースである「NFC-F」の利用が想定されていなかった。FeliCaを開発したソニーでは、こうしたHCEでもFeliCaの活用シーンを増やすべく、NFC-Fの仕様を盛り込んだ「HCE-F」の開発に着手することにした。

このHCE-Fの構想自体は2014年7月に東京都内で開催されたFeliCa Connect 2014にて同社でFeliCa事業部を束ねる坂本和之氏によって発表されたが、それから2年を経てAndroid 7.0 "Nougat"でついにHCE-Fが標準機能として盛り込まれることになった


↑Android 7.07 "Nougat"(API Level 24)に新機能として搭載された「HCE-F」

さて、このHCE-Fに関しては最近になり「Android Payで日本のFeliCa系サービスが利用可能になる」「グローバル携帯でおサイフケータイ未対応の機種でも利用できる」といった形で大きな話題になっていたりする。折しも、最新のiPhone 7でFeliCa SEを搭載してiD、QUICPay、Suicaが10月末に利用可能になる予定のほか、Android Payも間もなく日本上陸が近いといわれているところであり、このHCE-Fが日本の決済シーンにおける「台風の目」になるのではないかと考えられた点も大きい。

一方で、HCE-Fに関しては技術情報はほとんど出ておらず、その詳細がわからずに話題先行で盛り上がってしまっているきらいもある。今回、ソニーのFeliCa事業部 開発部で統括部長を務める米田好博氏と、同部3課 統括課長の中津留勉氏の両名にお話をうかがう機会を得たので、「HCE-F」の実際について紹介していこう。

なぜHCEなのか

まず最初にHCEについて改めて復習しておく。前述のように2013年11月にリリースされたAndroid 4.4 "KitKat"でサポートされたHCEだが、基本的には「ISO/IEC 14443-4」「ISO/IEC 7816-4」に対応してスマートフォン上で「非接触式ICカード」と同じ挙動をエミュレーションすることが可能になっている。つまり「カードエミュレーション(CE)」だ。通常のCEとの最大の違いは、CEの実現に専用のハードウェア(SE)を必要とせず、NFCコントローラからの通信制御をSEではなくホストCPU側に渡す点だ。これは専用ハードウェア(SE)を必要としない反面、セキュアなデータも含めてすべてホストOS側で処理する必要があり、例えば次のようなペナルティがある。
・セキュアなデータをホストCPUのみで処理する必要があり、安全性が担保されない

・処理のためにホストCPUが動作している必要があり、基本的に電源オフ時には利用できない(FeliCa SEを内蔵するおサイフケータイでは電源オフでもバッテリが少しでも残っている場合は動作する)

・専用ハードウェアを用いていないため、処理時間などは実装に依存する(必ずしもCPUの処理速度だけの問題ではない)

ひとつの問題について、当初HCEがAndroidに実装されたばかりのころは「ロイヤリティカードなど高い安全性が必ずしも必要とされない用途」に限定することで利便性をうたっていたものの、すぐにMasterCardやVISAなどの国際カードブランドが支持を発表し、安全性の問題は最終的に「トークナイゼーション(トークン化)」を併用することで解決した。カード情報をそのまま保持するのではなく、利用制限(回数や有効期限など)のかかった「トークン」を一時的に端末内に保管し、これで決済を行う。カード情報そのものはクラウド上に存在し、トークン利用ごとにオンラインで更新することで安全性を担保するものだ。この方式であれば、連続でなければオフライン状態でも利用が可能であり、Android Payはこの「HCE+トークナイゼーション」で実装が行われている。

またふたつめについては、当初Android Payでは「ホーム画面のロック解除」「アプリのロック解除」の2段階操作が要求されていたが、ロンドン公共交通(TfL)のオープンループのケースのように不自由を強いられる場合も考慮し、最近では決済が一定金額以下であればロック解除なしで操作可能な仕様も盛り込まれたようだ。こちらは未確認なので、近々ロンドンを訪問してチェックしてみたい。


↑専用ハードウェア(セキュアエレメント)を用いる通常のカードエミュレーション(CE)(左)とHCE(右)の挙動の違い [ph03.png]

なぜ、こうした各種ペナルティがあるにも関わらずHCEが利用されるかだが、Googleが過去にNFCを使った決済サービス提供で味わった苦労を考えれば簡単に想像できる。

同社は2011年にリリースした「Galaxy Nexus」に「Google Wallet」アプリを搭載して、今日広く認知されるようになった「モバイルウォレット」の仕組みをいち早く市場に投入しようと考えていた。ところがWalletアプリ搭載は、当時Galaxy NexusのローンチパートナーだったVerizon Wirelessに拒否され、最終的に2012年4月に同社が自らSIMロックフリー版をオンライン販売するまでは一般にはサービスが利用できなかった。現在はGoogleによる買収後にサービスを終了している「Softcard」(当時の名称は「Isis」)が、SIMカード方式のNFC決済サービス提供開始を控えており、携帯キャリア連合のジョイントベンチャー(JV)の1社として参加していたVerizon WirelessがGoogleの妨害にまわったという経緯がある。

結局、Walletアプリつき端末の携帯キャリア経由での流通はシャットアウトされ(JVに参加していなかったSprintを除く)、Googleはサービスのローンチもままならなかった。Galaxy Nexusは、iPhoneなどと同様に端末本体にセキュアエレメント(SE)を内蔵する「eSE」方式を採用していたが、こうした外的要因に振り回されたGoogleはカウンターパートとしてのSEを利用しない「HCE」に可能性を見出したと考えてもらえばいい。

HCE-Fの実際

さて、このような経緯でAndroidに導入されたHCEだが(最初のHCE商用実装は「BlackBerry」)、当初はType-Aのインターフェースである「NFC-A」への対応が必須で、Type-Bのインターフェースである「NFC-B」はオプション扱いとなっている。ただ、この状態ではFeliCaの「NFC-F」には対応しておらず、ソニーとして何らかの形でNFC-Fを盛り込めないかと模索したのが当初の経緯だったと前述の米田氏は説明する。

FeliCaとType-A/Bではプロトコルなど動作に細かな違いがあり、例えば「FeliCaでは最初に通信要求があった時点でNFCコントローラがすぐ返答しないとタイムアウトしてしまう」といった仕様が存在しており、NFC-Fを仕様として別途HCEに盛り込む必要があったようだ。仕様の盛り込みにあたっては「AOSP(Android Open Source Project)」へのコントリビューションという形態を採り、2015年初頭にはプロジェクトが開始され、最終的に2016年夏のNougatでの正式採用となった。

AOSPに仕様として盛り込まれ、HCE-Fを通じてFeliCaカードのCEが実現可能にはなったものの、最終的な実装そのものはGoogle側に依存しており、各種制限から現状では「おサイフケータイ」とはまったく異なる使い勝手となっている。制限の最たるものが「HCE-Fの利用にはアプリを最前面に出す必要がある」というものだ。

HCEはその性質上、要求に対するレスポンスは「アプリ」が反応することになるが、HCE-Fではレスポンスを返すアプリが最前面にある必要がある。つまり、使用にあたっては画面ロックを解除して目的のアプリを起動した状態で非接触リーダー等にかざしてやる必要がある。本体をタッチするだけでスムーズに改札やレジを通過したり、あるいはおサイフケータイのように「目的のアプリが自動選択される」ことはない。すべて手動で処理してやる必要がある。複数のHCE-Fサービスが同時に有効化されることはないとのことで、おそらく将来的にGoogleが別の形でHCE-F(で動作するアプリやサービス)をAndroid OSに直接実装しない限りは難しいのではないかと考える。

もう1つ、おそらく現状のHCE-Fの実装から推察して「電子マネー」としての利用は厳しいということが考えられる。Android Payでの決済はクレジットカード(またはデビットカード)が用いられ、安全性を担保する仕組みとしてトークンが使われたが、この仕組みが採用できたのも内部に「バリュー」を持たずに処理時間もあまり要求されないクレジットカードだからではないだろうか。電子マネーでは内部的にデータとして「バリュー(価値)」を持っており、決済時の処理の高速化と後処理での突き合わせによるデータの完全性を担保している。

セキュアエレメント的な仕組みをハードウェアで持たない以上、HCE-Fではアプリ側で何らかのデータ保持機構を持たねばならず、これがアプリやサービス構築のハードルとなる。処理速度の面でも、前述のようにメーカー各社によって実装がまちまちのため、例えばSuicaのような要求なシビアなケースでは検証が難しい。そのため、筆者の考えでは現状のHCE-Fで日本のFeliCaサービスをそのまま置き換えるのはほぼ無理だと思っている。

確かに、坂本氏が最初にHCE-Fのコンセプトを発表した際に「HCE-Fは既存のFeliCaサービスを置き換えるものではなく、用途を拡大していくもの」と説明していた。現在Nougatに実装されているHCE-Fはその説明そのままの仕様であり、「これから登場する新しいFeliCaアプリケーション」のために用意されたものだといっていい。


↑HCE-Fの用途を説明する坂本氏。まさにHCE-Fはこの新しい市場を狙った規格だった

米田氏によれば、現状は仕様が公開されたばかりの段階で、今後この仕組みを使ってアプリケーションを開発するパートナーやデベロッパーにアプローチしていきたいという。比較的近いタイミングで仕様をまとめたホワイトペーパー的なものが公開されるとみられるが、セキュリティ的に厳密なFeliCa向けアプリケーションに比べ、HCE-Fそのものはオープンな仕様であり、参入ハードルは低いと想定される。今後Nougatやその後継OSが多くのAndroidデバイスに搭載される2~3年後には、何らかの形で対応アプリケーションが増えていることだろう。

ところで、今回iPhone 7にはFeliCaが搭載され、日本のおサイフケータイで利用されていたサービスの「一部」がそのまま利用できるようになっていたことが話題になっている。AndroidにおけるHCE-Fは、グローバル端末をそのまま日本に持ち込んでFeliCaサービスを利用できる印象を抱いていた方がいるかもしれないが、少なくともFeliCa SEなしでのサービス実装は当面難しいのではないだろうか。その意味で、Appleの日本専用モデル提供という実装は「現在ある最適解」の結果なのかもしれない。
海外の格安スマホでもFeliCaが利用可能になる? 「HCE-F」の正体を探る:モバイル決済最前線
広告

0 コメント

広告