Apple Payと何が違う？『Samsung Pay』の秘密に迫る：MWC 2015

2015年03月06日 08時00分更新



すると、異なる番号（トークン）となって端末には記録される。

　　Apple Payではカード情報を登録する際、カード発行者が持つサーバにトークン生成のリクエストが送信され、ここでトークン化された番号をiPhoneが受け取り、内蔵のSE内に決済用カード番号として記録する。クレジットカードの16桁のカード番号は“PAN（Primary Account Number）”と呼ばれているが、ここで発行されるトークンもまた16桁の番号を持っており、カード決済を受け入れる小売店（アクワイアラ）から見る範囲では通常のPANとトークンの区別はつかない。既存のPANをベースとした決済インフラでもトークンがそのまま使えるように、このような仕組みになっている。

　支払いの際に小売店の読み取り端末を通して決済ネットワークを通過したトークンは、カードブランド（MasterCardやVisaなど）のサーバでいちど本来のPAN番号へと変換され、カードを発行する銀行（イシュアへと渡される）。つまり本来のPANを知っているのは銀行とカードブランド、そしてカードの所有者だけとなる。

■用途に応じてカード番号を使い分けられる“トークン化”

　トークンを利用するメリットは“本来のカード番号を隠蔽（いんぺい）”することもそうだが、なにより“用途に応じてカード番号を使い分ける”ことが可能になる点が大きい。

　例えば、家族で1枚のカードを共有する場合、それぞれにトークンを発行して使い分ければ、万が一、ひとりのトークンが流出したとしても、当該のトークンを無効にするだけで済み、トークンごとの利用状況の管理も容易なため、安全性と管理面で都合がいい。また、ひとりが複数のデバイスを所持していたり、利用するサービスごとにトークンを発行した場合、デバイスを紛失したり、特定のサービスからカード情報が流出したとしても、やはり当該のトークンを無効化するだけでよく、カード再発行の必要がない。こうした細かいカード情報の管理を“ドメイン化”と呼び、実際に1枚のクレジットカードをトークナイゼーションを利用して複数のデバイスで利用した場合、このようなドメイン化が実現できる。

　Samsung Payでは、このトークナイゼーションの機能が利用できるとしている。詳細は不明だが、LoopPayでも同様にトークナイゼーションへの対応を説明しており、おそらくApple Pay同様に、カード情報登録時にトークン化を行ない、本体に記録されるカード情報はPANではなくトークン、ということなのだろう。



LoopPayの提供するウォレット。同社は2月にSamsungによる買収が発表された。



LoopPayによる磁気カード読み取り機での決済の様子。

　ただ、ここにトリックがあり、もしSamsung Payが“トークナイゼーションを必須事項”としていた場合、当然同サービスが利用できるのは“トークナイゼーションが利用可能な地域”に限定されるという問題がある。例えば、MasterCardではMDES（MasterCard Digital Enablement Service）、VisaではVTS（Visa Token Service）というトークナイゼーションというサービスを提供しているが、どちらも現在利用可能な地域が米国に限られている。

　現在、Apple Payが米国のみで利用可能な理由のひとつがここにあり、これらカードブランドの“トークナイゼーション・サービスの提供地域が広がる＝その地域でApple Pay（または類似サービス）が利用可能になる”ということを意味している。

　先ほど、SamsungがSamsung Payの最初の提供地域を“米国と韓国”としていたが、韓国が後回しになるとみられる理由がここにある。おそらく、2015年後半にかけて北米や欧州を中心にトークナイゼーションの利用可能地域が広がっていくと思われるが、それはつまり“こういうこと”なのだと認識していて問題ないだろう。

■Samsung Payの根幹を成す“KNOX”と“TEE”

　トークナイゼーションと並んでSamsung Payで重要なのが“TEE（Trusted Execution Environment）”というキーワードだ。ARM11以降のARM系プロセッサでは“TrustZone”という機能を備えており、プロセッサー内でメインのOSとは別に完全に隔離された実行領域を確保することが可能になっている。

　この上で動作するOSは“セキュアOS”などと呼ばれ、メインのOSからはその存在を直接把握できない形で存在している。例えば、DRM付きコンテンツの再生にもTrustZoneの仕組みが使われていたりするが、これはDRMの管理がセキュアOS上で行なわれるため、万が一、メインOSのAndroidがハックされていたりしても、DRMの部分には手を付けられないからだ。この性質を利用し、セキュリティー機能としてTrustZone上に実装されたのがSamsungの“KNOX”で、企業での秘密情報の保護や、デバイス管理など、“素”の状態のAndroidでは難しいとされている部分の補完を行なうことを目的としている。

　このように、TrustZoneでメインOSとセキュアOSの2つの領域にシステムを分割する理由のひとつに、“AndroidのようなメインOSはリッチ化が進み、脆弱性やバグなどハッキング対策が不十分になりやすい”という背景がある。

　セキュアOSは仕組みとしては非常にローレベルのもので、機能は限られるが動作は厳格であり、高い信頼性で構築されている。このセキュアOSにおける業界標準とも呼べるのが“TEE”だ。

　TEEは、ICカードや決済手順などを業界標準をまとめているGlobalPlatformによって定義されており、モバイル環境において共通かつ安全なやり取りを可能にすることを目的としている。仕組みとして厳密に内部データが保護されるため、ICカードのチップやSIMカード、前述セキュアエレメント（SE）の代わりとしての利用が可能だと思われるが、少なくとも数年前までは、会員カードみたいに、クレジットカード情報よりもセキュリティ要件の低いものとされ、業界全体ではTEEの信頼性はそれほど高くないものとして扱われていた印象が強い。

　だが今回のMWCで、ARMのセグメントマーケティング担当バイスプレジデントのIan Ferguson氏と、前述MasterCardのJames Anderson氏の2人のコメントを参考にする限り、Samsung PayはこのTEEを使って“ソフトウェアベース”で実装されている可能性が高いとみられる。



米MasterCardのモバイル担当SVPのJames Anderson氏。

　Apple PayではiPhone内に専用のセキュリティーチップを内蔵し、ここにトークン情報を記録しているが、少なくともSamsung Payは、TEEを使って汎用ストレージに暗号化した状態でトークンを保持しているということになる。

　前述のようにGalaxy Sシリーズは、S4以降にSEを本体に内蔵しており（eSE）、さらにSIMカード内のセキュアなデータ領域にSWP（Single Wire Protocol）を使ってアクセスできるようになっている。つまり、可能性としてはSIM、eSE、TEEの3種類がNFCでの決済に利用できるが、このうちのTEEを決済に用いている、と考えていいだろう。

　筆者の把握する限り、決済目的でのTEE利用は初のケースだ。以前まで、金融関係者やサービスプロバイダ、携帯キャリアなどは安全性の理由からハードウェアベースの専用チップ利用を推奨しており、ソフトウェアベースのソリューション選択には否定的な雰囲気があったが、もしSamsung PayがTEEを利用するというのならば、これは大きな方針転換で非常に革新的な話題だ。

　これはいくつかのことを示唆している。

　まず、Googleが推進している、専用チップを使わずにメインOSからNFCを利用する“HCE（Host Card Emulation）”という技術があるが、アイデア的にはTEEのそれに近い。ポイントのひとつは、カード番号など決済情報の本体が“クラウド上”にあるという点。NFC決済においては、このクラウド上のカード情報をインターネット経由でスマートフォン端末のOSへと引っぱってきて、NFCを通じてカード読み取り機にカード情報を転送する、という手順を経る。これだとオフラインでは利用できないことになるが、TEEなどのセキュア領域を用いて一時的にトークンを保存しておくことで、オフライン時の決済に利用できる。

　ここで“トークン”と“TEE”という2つのキーワードが出てくるが、Samsung Payが同じ仕組みでサービスを提供できるのであれば、GoogleもまたHCEを使って同様の“ソフトウェアベース”となる決済ソリューションの提供が可能になるということだ。



ARMのセグメントマーケティング担当バイスプレジデントのIan Ferguson氏。

　MWC2015では、初日にあたる2日の基調講演で、米Google製品担当SVPのSundar Pichai氏が『Android Pay』の話をして話題となった。

　Android Payの可能性のひとつとして考えられるのは、つまりSamsung Payのような決済システムを“HCE”と“TEE”を使って構築するのでは、ということだ。AndroidではNFC利用のためのAPIを提供しているが、カード決済に必要なNFC利用モードの1つ“Card Emulation（CE）”が標準実装されておらず、これがAndroidにNFC決済の仕組みを組み込むうえでのネックとなっていた。Googleとしては、標準APIを提供することで、端末ベンダーやアプリ開発者の負担を減らすことが狙いのひとつとみられ、その基本技術として、上記のような仕組みを採用することは十分に考えられる。

　もっとも、Pichai氏は具体的な話には踏み込んでおらず、“今後数ヵ月内”に改めて説明すると述べるに留まった。

　目処としては、今年5月に開催される開発者会議Google I/Oでの発表に注目しておくといいだろう。ちなみに同社は、米携帯キャリア連合のジョイントベンチャー、Softcard（旧名：Isis Wallet）の買収を発表しており、HCEよりもむしろSIMカードベースの決済に興味を持ち始めたのではという意見もあるが、いまひとつ方向性が見えていない。だがAndroidをオンラインでもオフラインでも決済において活用できる仕組みを模索しているのは確かで、その総称が『Android Pay』のようなブランド名で呼ばれるようになるのかもしれない。

■関連サイト
Microsoft