- 実際のカード番号を隠す仕組みは Apple Pay固有の機能 ではなく、Google Pay・Samsung Pay など主要なデジタルウォレットでも使われている決済方式である
- 核心は、物理カード番号である FPAN と、デバイスごとの決済番号である DPAN の分離であり、同じカードでも iPhone と iPad では別々の DPAN が使われる
- DPAN は加盟店をまたいだ追跡を難しくできるが、同じ加盟店内では継続的な取引でも維持されるため、単一加盟店での購買履歴の追跡 までは防げない
- 決済情報が漏えいした際は FPAN より DPAN のほうが安全であり、DPAN は取引ごとに付与される 固有の暗号化バンドル と一緒に提出されたときにのみ機能する
- Apple Pay は氏名、メールアドレス、請求先・配送先、購入商品といった 個人情報 を自動的に隠すわけではなく、決済画面に表示された情報は加盟店に渡ると考えるべきである
DPAN は Apple Pay 専用機能ではない
- Apple Pay が実際のクレジットカード番号を隠すと言うとき、その中核にあるのは DPAN である
- FPAN は物理カードに印字された 15〜18 桁の funding primary account number であり、DPAN は device primary account number である
- DPAN は DNS レコードに近いものとして理解できる
- ユーザーは実際の IP アドレスを知らなくても、ドメイン名で Web サイトにアクセスできる
- 同じカードでも Apple Pay を iPhone と iPad で使えば、それぞれのデバイスが固有の番号を受け取り、異なる DPAN を使う
- 名前からして “Apple Pay number” ではない点が重要である
- Google Pay や Samsung Pay も、米国の主要なデジタルウォレットとして同じ方式で実際のカード番号を隠している
- Amazon Pay や Shop Pay のボタンも、決済が別会社を通じて処理されるため技術的には DPAN ではないが、加盟店が実際の FPAN を見られないようにしている
加盟店と銀行も実際のカード番号の露出を減らしたい
- 加盟店が実際のクレジットカード番号を直接処理すると、リスク負担 が大きくなる
- 現代の決済受け入れツールは、実際のカード情報にアクセスできる人を可能な限り減らす形で決済情報を収集するよう作られている
- 銀行が DPAN を使わないだろうという推測は、実例と一致しない
- Wells Fargo、Chase、Bank of America など多くの銀行は独自のデジタルウォレットを運営している、または運営してきたが、いずれも DPAN によって通常の口座番号を保護している
- 米国の大手銀行が使う Paze も DPAN を使用している
- Paze が掲げる主な理由のひとつは “Paze does not share your actual card number with the merchant.” である
DPAN が防ぐ追跡と防げない追跡
- DPAN が 取引ごとに変わる という説明は正確ではない
- 同じ加盟店で継続して行われる取引には、同じ DPAN が使われる
- この仕組みは、複数の加盟店の取引データを買い集めて一人の買い物傾向を把握しようとするデータブローカーにとって障壁になり得る
- 一方で単一の加盟店は、Apple Pay が提供した DPAN だけでも、その顧客の取引履歴を見ることができる
- Target が自社の購買履歴をもとに顧客の状態を推測した事例のような状況を、Apple Pay が防ぐわけではない
- 他のデジタルウォレットにも同じ限界がある
データ漏えい時に DPAN がもたらす保護
- 決済カード情報が漏えいする状況では、DPAN は FPAN より安全 である
- 2024 年に加盟店がクレジットカード番号を直接扱うことはあってはならないが、決済ゲートウェイが侵害されて DPAN と有効期限が漏えいする状況は起こり得る
- 攻撃者は漏えいした DPAN だけで決済を実行することはできない
- DPAN は各取引に固有の暗号化バンドルの一部として提出されたときにのみ機能する
- Apple Pay で収集されたカードに対して継続課金を実行する方法はあるが、ハッカーがそれをできてはいけない
- そのため、すべてのデジタルウォレットが収集する DPAN の漏えいよりも、FPAN の漏えい のほうがはるかに危険である
Apple Pay は個人情報を自動的には隠さない
- Apple Pay が個人情報を自動的にマスクするという考えは事実ではない
- テスト用加盟店アカウントで実際の Apple Pay 取引を実行すると、加盟店レベルのレポートには氏名、メールアドレス、請求先や自宅住所といった情報が表示される
- 物理商品の決済には 配送情報 が必要なため、Apple Pay SDK は加盟店が顧客から受け取る個人情報を選べるようにしている
- 商品情報も Apple Pay に渡され、購入者が何を買うのかを表示でき、この情報も加盟店に渡される
- 決済時に Apple Pay カードに表示される情報は、加盟店に渡ると考えるべきである
- この点で Apple Pay は他の決済方式と同じである
- 加盟店はチェックアウト時に、必要または望む個人情報を選んで要求する
- 他のデジタルウォレットも同じ方式で動作する
デジタルウォレットが実際に提供する保護
- Apple Pay は優れた決済手段であり、Apple はこの種のデジタルウォレットを一般化するうえで役割を果たしてきた
- ただし Apple Pay の機能は業界で 固有のものではない
- DPAN は、複数加盟店にまたがる一人の購買追跡を難しくし、決済カード情報が漏えいした際の顧客リスクを減らすのに有用である
1件のコメント
Hacker News のコメント
Apple Pay と Google Pay が実際にどう動作しているのか、ELI5 で知りたい。以前はカード情報を加盟店や決済代行会社にそのまま渡していると思っていたし、原文も似たように見えるのだが、Google Pay で Amex を使うと MasterCard のときと違って一部の加盟店が決済を拒否するのも見たことがある
ときどき Apple/Google が決済代行会社や決済手段そのもののように振る舞っているように感じる。取引データを集めていて、スーパーの端末も Apple/Google Pay アプリ向けの特別な対応が必要だったように見えたからだ
だとすると、Apple/Google だけの独自の秘訣は何なのか、なぜオープンソースの代替で置き換えるのが難しい、あるいは不可能なのかが気になる。iOS/Android で NFC チップに完全にアクセスできるのが Apple/Google だけだからなのか？
https://news.ycombinator.com/item?id=39845805
重要なのはデフォルトであることだ。端末ごとにデフォルトの Visa、Mastercard ウォレットは1つしか置けず、タップする前に別途アプリを開く必要がないほうが有利だ。Google Pay は複数の銀行カードをサポートするため、特定の発行銀行の HCE ウォレットより大きな利点がある
Apple/Google は新しいカードを特定の端末に登録するときの仲介には関与するが、実際の POS 取引フローには入らない
加盟店は依然として基盤となるカードブランドを受け入れる必要がある。現在の Google Pay と Apple Pay はカードブランドを切り替えるプロキシカードではなく、Curve のようなサービスとは異なる
オフライン端末に別途対応は必要ない。端末にバグがない限り、基盤となるカードスキームを受け付ける場所なら動作する。物理・論理プロトコルはプラスチックカードと同じで、端末側からはほとんど区別できない
Web では事情が異なる。EC サイトと決済サービスプロバイダーが明示的に対応する必要がある
そのため無線端末はたいてい Apple Pay と Google Pay をそのまま受け付け、特別な対応はあまり必要なかった。変わったことの一つとして覚えているのは、こうしたデバイスはより安全だと見なされ、非接触カードより決済限度額が引き上げられた点だ
オープンソース実装が難しい理由は、EMV の実装が複雑で、専門機器による多くのテストと検証が必要だからだ。端末には秘密鍵を安全に保管するセキュア領域が必要で、アプリは生体認証や PIN によるロック解除が使われたことを確認し、ユーザーの安全性を保証できなければならない
また設定プロセスでは、カード発行銀行のバックエンドと連携して必要な鍵と情報を発行してもらう必要がある。オープンソース実装であっても、銀行と契約し、UL のような機関によるラボ検証を経る必要がある可能性が高い
Apple Pay と Google Pay、銀行提供の決済アプリは、生体認証でカード保有者の承認を確認し、一部の決済を「カード保有者存在」に変える
そのため一部のチャージバック種別は即座に却下され、他の種別でも加盟店に求められる証明のハードルが下がる
これはカードネットワーク標準の一部で、興味があれば https://www.emvco.com/ で見られる
オープンソースの選択肢がない理由は、実装のセキュリティを認証する必要があり、銀行と取引する商業主体が必要だからだ。加えて銀行ごとに個別統合が必要なので、相手にしなければならない銀行が多すぎる
すべてのカードスキーム、すべての決済方式、すべての端末をまたぐエンドツーエンドの取引を正しく動かすのはかなり厄介だ。カードスキームごとに対応する「決済カーネル」パラメータや認証要件が異なる
あるいは取引手数料を節約しようとしているのかもしれない。Amex は一般に加盟店にとってはるかに高い
https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...
Apple Pay が最初に広く使われ始めたころ、小売決済処理の経験をもとにかなり詳しく調べた。当時いちばん印象的だったのは、それがどれほど業界標準に深く根ざしていたかという点だった
無線通信以降のどの部分も Apple 専用ではなく、この記事を読むかぎり、その点はいまも維持されているように見える
当時、カードベースのタップ・ツー・ペイを意図的に受け付けていた一部の加盟店は、非常に標準的な Apple のタップ・ツー・ペイを意図せず受け付けることになり、システムを変更せざるを得なかったと記憶している。特に CVS が思い浮かぶ。競合する決済スキームに参加していて、そのスキームが店頭で使えることを Apple Pay との差別化点にしたかったのだと思う
最近「これは Apple Pay だけがやっている」という神話が生まれ始めたとき、自分が最後に見たあとに何か変わったのかと不思議に思っていたので、筆者がこの文脈で最新の検証をしてくれてうれしい
公式サポートではなかったにもかかわらず、オーストラリアのどこでも Apple Pay が動作して、かなり驚いた。米国ではごく一部の加盟店しか対応していなかったが、オーストラリアは標準ベースだったため、POS の 99% がすでに対応していたということだ
Android 決済の混乱した状況も一役買っていた。Samsung Pay は NFC を指すこともあれば、磁気ストライプのエミュレーションを指すこともあった。Google はブランディングが下手なことで有名で、Wallet と Google Pay の何度もの変遷のあいだで、いまでも何が何なのか把握しにくい
こうした議論で抜けているのは、Apple Pay や Google Pay、Samsung Pay のようなウォレットの取引も、いまでは元のカード番号による取引と同じくらい追跡可能だという点だ
DPAN は特定のデバイスに固有だが、最近では加盟店の決済サービスプロバイダーは、カードネットワークの承認応答から PAR という一意の識別子を受け取れる。この識別子は同じカードのすべての DPAN で同一であり、同じ基本口座であればカード番号が変わっても維持される方向を目指している
PAR では加盟店が決済請求を行うことはできないのでセキュリティ上の問題ではないが、デジタルウォレット決済が通常のカード決済やカード番号決済よりプライベートだと期待すべきではない
https://wcapra.com/payment-account-reference-capraplus-your-...
https://www.securetechalliance.org/wp-content/uploads/EMVCo-...
Matt Birchler の記事には「以前のバージョンでは DPAN が加盟店ごとに変わると書いたが、誤りだった。急いで書きすぎた自分のミスだ」という段落が追加された。だが記事の残りの部分は、いまだに加盟店ごとに固有の DPAN があるかのように見え、その根拠は見つけられない
Apple 自身の文書 https://support.apple.com/en-us/HT203027 も、DPAN、ここでは Device Account Number がデバイスごとにのみ固有だと述べている。カードが Apple Pay に追加されると、そのデバイスの DPAN が生成され、カードを削除して再追加しないかぎり、その後は変わらない
そのため、同じカードを iPhone と Apple Watch の 2 台で使えば DPAN が異なるので追跡されにくいが、同じデバイスで同じカードを複数の加盟店で使えば、データブローカーは追跡できると思う
なぜSSOやモバイル決済が、誰でもプロバイダーを作れる標準インターフェースになっていないのか分からない。「Login with Google」や「Login with Apple」の代わりに、「自分のデフォルトSSOプロバイダーでログイン」があるべきではないのか。「自分のデフォルト決済プロバイダーで支払う」も同じだ。
さらに悪いことに、ベンダーやサイトがこうしたプロバイダーの一部しかサポートしないことが多く、SSOが実質的にSSOではなくなっている。
理由はあるのだろうが、深く調べたわけではない。すべてのプロバイダーが従う共通の合意仕様があるべきだと思うし、なければいずれ法律でそう強制される可能性が高い。
標準はすでにあり、理論上はログインフォームにメールアドレスを入力するか、ブラウザが自動入力すれば、そのドメインのOAuthログインにつながり、サーバーがそのドメインと初めて通信する場合は、その場でクライアント登録までできる。実際に使われているのは見たことがないが、あればよいと思う。
[0] https://datatracker.ietf.org/doc/html/rfc7591
[1] https://datatracker.ietf.org/doc/html/rfc8414
サービスを提供して公正な料金を受け取る側から、ユーザーにスパムを送りつけたり、データを集めて後でもっとスパムを送ったりする側へ移行した。
オープン標準は、現在のプロバイダーたちが望むものではない。そうなるとユーザーが簡単に別の選択肢へ乗り換え、もはや「エンゲージ」しなくなるからだ。
興味深いことに、Apple Payはオーストラリアの大手銀行が何年も非接触決済の利用拡大を推し進めた後に登場した。だからAppleが参入して米国式の手数料を要求したとき、インフラはすでに銀行が自前で敷いていた。
オーストラリアの大手銀行は何年もApple Pay対応に抵抗したが、顧客からの圧力が大きくなりすぎ、結局折れた。
今でも皆この件に非常に不満を持っており、規制当局がNFCチップの開放を強制すれば、即座にApple Payを捨てるだろう。だがこれまでのところ、国内最大手の銀行たちの泣き言に共感してくれる人を見つけるのは難しかった。
https://www.accc.gov.au/media-release/accc-denies-authorisat...
カナダの銀行もAndroidでTD Payのような独自の非接触決済を試したが、誰も望まなかった。結局あきらめてGoogle Payを提供した。
同じような流れになると思う。AppleがNFC決済を開放しても、誰も銀行アプリを使わず、Apple PayやGoogle Payのようなファーストクラスのサポートを好むだろう。
Samsung PayとGoogle Payのうち、実際にどれだけの人がSamsung Payを使っているかを見れば十分だ。
CVSのような一部の小売業者は、Apple Payが導入されるとタップ決済をオフにした。
「加盟店はチェックアウトで必要なだけ個人情報を求めることができ、Apple Payはそれを妨げない」という部分が、オフラインでの買い物でも起きるのか気になる。
卵をスーパーで買うのに、自分の名前や住所は必要ない。Apple/Googleは、明らかに不要な情報まで共有するときに、自分の同意を求めるのだろうか。利用規約やシュリンクラップEULAのように、受け入れるかやめるかという方式なのか。
こういう決済システムは使ったことがない。
記事で触れられている追加情報は、「オンライン」決済でのみ共有される。ただしこれには、スマートフォンでQRコードをスキャンしてSafariやApp Clipで支払う場合も含まれ、最近いくつかのレストランで見た方式だ。
そうすると、レストランは要求しただけの情報を受け取る。名前、住所、メールアドレスまで含まれ得る。通常は決済シートに表示されているようだが、初めてレストランで使ったときはよく認識していなかった。
今ではウェイターに実際の端末を持ってきてもらってタップさせてもらうか、単に物理カードを渡している。
少し本題から外れるが、Apple Pay が取引承認の前に、いま支払う金額を画面に表示できない理由がいまだに理解できない
ユーザー体験の問題ではなく、Apple デバイスがその金額をそもそも知らないように見える。なぜなのだろう？
これを理解するのに少し時間がかかった。機内モードで Apple Pay がどう動作するのか理解できなかったが、当然動作する。既存の Visa カードもインターネット接続なしで問題なく使えるからだ
根本的には両者は同じものだ。全員が標準どおりに動作すれば、追加で「対応」するものがない理由もそこにある。jjcm の兄弟コメント参照: https://news.ycombinator.com/item?id=39846117
だから NFC リーダーは支払金額を「ブロードキャスト」していないのだと思う。プラスチックカードにはその情報を処理する方法がなかったし、iPhone もその情報を受け取って「ちょっと待って、ユーザーがスワイプで承認するまで待て」と言う方法がない
Gruber が「これは Apple Pay だけがやっている」とどこで言ったのか分からない。筆者は Gruber がいくつか間違えた点や、細部を正確に把握していなかった部分を指摘していて、それがすべてのように見える
[更新: しまった、私が間違っていた。決済業界で働く Matt Birchler が仕組みをうまく説明しており、大手銀行やクレジットカード会社がタップ・トゥ・ペイ取引で加盟店ごとの「DPAN」番号を生成していることが明らかになった。それでも Apple Wallet は、カード発行会社が提供するどのデジタル決済アプリと比べても、少なくとも同等、あるいはより安全だという私の主張は維持する。]
原著者である Gruber の記事
Gruber も自分の誤りを認めた
Gruber は公然たる Apple ファンだが、概して事実関係は押さえており、分からない部分は認め、その分野の専門家にリンクするタイプだった
しかし EU DMA に対する Apple の対応以降は、客観性を完全に失ったように見える。EC よりも法文をよく理解しているふりをし、かなり異なる欧州の立法方式に米国流のアプローチを当てはめ、Apple の悪意ある発言をそのまま受け入れている
この変化は、Apple の EU に対する妙に悪意ある態度と重なっており、根本的な問題は Gruber が Apple を信頼しすぎていることなのかもしれない
米国政府の反トラスト訴訟に対しても、その態度を続けているように見える
公平に言えば、ソーシャルメディアには法律専門家のふりをする Apple 支持者があふれていて、ほとんどすべてを間違って語っているため、彼が正当な反対意見を見るのは難しいのかもしれない
「Apple はこうしたデジタルウォレットを普及させる上で素晴らしい仕事をしたが、彼らがしていることは業界で固有のものではない」という部分について、記憶違いかもしれないが、Apple Pay が最初に出たときはかなり独特だったと思う。だから対応している場所が非常に少なかった
他の携帯電話決済システム、たとえば初期の Samsung Pay などは、カード番号を端末にそのまま送っていたように思う
興味深いことに英国では今でも £100 の上限があるようだが、米国では Android 携帯の非接触決済で $2000 を超える金額を支払ったこともある
おそらく銀行にだけ直接送っていて加盟店は見られなかったのかもしれないが、それでも実番号だった。DPAN を使ったと初めて聞いたのは Apple だった
米国はさまざまな理由でカード決済技術が大きく遅れている。ポーランドから、世界中で何年も使っていたカードを持って訪れたとき、レジ係が決済できるようにするための特殊な回避方法から学ばなければならなかったほどだ