⇧ ちょっと前に、Java製品をクラッシュさせる不具合を生み出していましたが、またもや、Apple製品で不具合と、『どうした！？Apple』と思っていたら、
⇧ 本来の姿に戻っているだけなんかね？
何と言うか、
⇧ 市場独占を疑われているぐらいだから、膨大な利益を上げてると思われるからして、潤沢な資金はあると思われるのに品質低下って、開発に十分な予算が割り当てられていないんかね？
そして、
⇧ 肝心な時に役に立たないAI...
プログラミングの学習しないで済むなら、ありがたいんですけど、AIの精度が100%にならない限り、人手でプログラミングの内容を解釈せざるを得ないので、まぁ、無理でしょうな...
AIが提案するソースコードにしろ、stackoverflowのようなサイトで提案されているソースコードにしろ、適切なプログラミング内容なのかを判断するためにプログラミング学習せざるを得ないかと。
とりあえず、ソフトウェアのエンジニアを生業にしてる人は、プロダクトとして使い物になるソースコードになっているかどうかを判断するために、プログラミング学習が必要なんでしょうな。
つまり、苦行は続くということですな...
世の中、プログラミング大好きっていう、超人もおられると思うので、そういった方にとっては苦行でも何でもないと思いますが...
自分にとっては、苦行以外の何物でもないです（涙）
なので、早くAI様が、行住坐臥、全くの例外なく精度100%を叩き出して、苦行に苛まれている衆生を救済して欲しいと思う今日この頃です、合掌。
PCI SSC (Payment Card Industry Security Standards Council)とは
何やら、
⇧ 最近、今時の「クレジットカード」による決済のセキュリティ事情などが紹介されてたらしい。
3-D Secure is a protocol designed to be an additional security layer for online credit and debit card transactions. The name refers to the "three domains" which interact using the protocol: the merchant/acquirer domain, the issuer domain, and the interoperability domain.
Originally developed in the autumn of 1999 by Celo Communications AB (which was acquired by Gemplus Associates and integrated into Gemplus, Gemalto and now Thales Group) for Visa Inc. in a project named "p42" ("p" from Pole vault as the project was a big challenge and "42" as the answer from the book The Hitchhiker's Guide to the Galaxy). A new updated version was developed by Gemplus between 2000-2001.
In 2001 Arcot Systems (now CA Technologies) and Visa Inc. with the intention of improving the security of Internet payments, and offered to customers under the Verified by Visa brand (later rebranded as Visa Secure). Services based on the protocol have also been adopted by Mastercard as SecureCode (later rebranded as Identity Check), by Discover as ProtectBuy, by JCB International as J/Secure, and by American Express as American Express SafeKey.
Later revisions of the protocol have been produced by EMVCo under the name EMV 3-D Secure. Version 2 of the protocol was published in 2016 with the aim of complying with new EU authentication requirements and resolving some of the short-comings of the original protocol.
⇧ とあるように、「EMVCo」という組織が関わっていると。
「EMVCo」はと言うと、
EMV is a payment method based on a technical standard for smart payment cards and for payment terminals and automated teller machines which can accept them. EMV stands for "Europay, Mastercard, and Visa", the three companies that created the standard.
EMV chip specification
The first version of EMV standard was published in 1995. Now the standard is defined and managed by the privately owned corporation EMVCo LLC. The current members of EMVCo are American Express, Discover Financial, JCB International, Mastercard, China UnionPay, and Visa Inc. Each of these organizations owns an equal share of EMVCo and has representatives in the EMVCo organization and EMVCo working groups.
⇧ とあり、「クレジットカード」のブランド会社で構成されていたっぽい。
話が脱線しましたが、セキュリティ関連の話で続けていくことにして、見出しで触れてる「PCI SSC (Payment Card Industry Security Standards Council)」について、Wikipediaさんによりますと、
PCI SSC (Payment Card Industry Security Standards Council)は、PCI DSSの継続的な発展、管理を目的として、アメリカン・エキスプレス、ディスカバー・フィナンシャル・サービシズ、JCBインターナショナル、マスターカード、Visaの5社によって、2006年9月7日に設立された評議会である。評議会自身は、さまざまなカード会社から構成されているが、カード会社とは異なる独立した機関であるとしている。
概要
PCI SSCは「Payment Card Industry Data Security Standard (PCI DSS)」の一連のセキュリティ基準の編成を行なった。これらの基準は、企業自身がカードのセキュリティ方針、手順、ガイドラインを評価するために盛り込まれた多数の下位要件を含む12の重要な要件で構成されている。
この評議会では、かつて決済アプリケーションのベストプラクティス (PABP)と称されていた「Payment Application Data Security Standard (PA-DSS)」の管理も同様に行なっている。
2016年からは、EMVcoと協力してEMV3Dセキュアv2.0をサポートするためのセキュリティ要件、テスト手順、評価者研修を提供している。
⇧とのこと。
元々は、「クレジットカード」を利用した取引に関するセキュリティを整備する目的で「PCI DSS（PCI Data Security Standards）」が策定され、「PCI DSS（PCI Data Security Standards）」をメンテナンスのために発足された機関ということらしい。
PCI SSCが管理してるっぽいセキュリティ標準について
「PCI SSC (Payment Card Industry Security Standards Council)」のサイトが公開している情報によると、
listings.pcisecuritystandards.org
⇧ 上記のように、いくつかのセキュリティ標準に分かれているらしい。ステークホルダー毎に分かれているってことなんですかね？
上図の大きさが変わっていることから推測すると、
⇧ みたいな分類になるんかな？
何やら、
⇧「NIST Cybersecurity Framework」なるものと共通する部分があるらしいと。
上記のベン図（Venn diagram）は、マッピングの概要を表わしているようなのですが、『Mapping PCI DSS v3.2.1 to the NIST Cybersecurity Framework v1.1』というタイトルのPDFを覗いて見た感じだと、
- COBIT 5
- ISA 62443-2-1
- ISA 62443-3-3
- ISO/IEC 27001
- NIST Special Publication 800-53
- PCI DSS
- CIS CSC
- OBIT 5
あたりの登場人物がおったのだが...
いや、これ、全部、確認とか無理でしょ...、何年かかるって話よ...
と言うか、マッピングした人、どれだけの工数かかったんだろうか...
しかも、上記の資料が2019年頃のものらしいので、「PCI DSS（PCI Data Security Standards）」以外の仕様も変更あったりしてそうですし。
こういう部分こそ、AIに頑張ってもらいたいんだが...
PCI SSCが管理してるっぽいセキュリティ標準と電子決済の関係を整理したかったが...
で、皆様、お察しの通り、「PCI SSC (Payment Card Industry Security Standards Council)」というのは、元々、「クレジットカード」による決済処理に絡んでくるデータに対するセキュリティ標準であったと思われる「PCI Data Security Standards（PCI DSS）」を管理する目的で発足された機関らしいですと。
ちなみに、
PCI DSS（Payment Card Industry Data Security Standard = 支払カード産業データセキュリティ規格）は、 クレジットカード情報および取り引き情報を保護するために2004年12月、JCB・American Express・Discover・マスターカード・VISAの国際ペイメントブランド5社が共同で策定した、クレジット業界におけるグローバルセキュリティ基準である。
2022年3月に最新版であるv4.0が発表された。2024年3月末までは、v3.2.1とv4.0がともに有効であるが、2024年3月末にv3.2.1は引退し、v4.0のみが有効な基準となる。
管理団体
上記5社がPCI SSC (Payment Card Industry Security Standards Council)を設立し、PCI関連基準の策定・維持、評価手順の確立、認定審査会社の教育・試験等を実施している。
制定の経緯
クレジットカード、デビットカード、プリペイドカードに代表されるカード決済は、その利便性により、店舗やウェブ決済での使用比率が増えていき、膨大なカード情報の管理が必要となった。それに伴い、カード決済に関わるシステムやネットワークのセキュリティが侵害されることによる、カード利用者、決済店舗、カード発行会社が損害を受ける事態が広がっていった。主要カード会社は、独自のセキュリティ対応策を開発し加盟店へ順守を促したが、カード会社それぞれが独自に指示をしたため対応がまとまらず大きな成果はでなかった。その後、増大するセキュリティリスクへの懸念を払拭するため、2004年12月に主要カード会社が共同で PCIデータセキュリティスタンダードをリリース、2006年に PCI SSC を設立した。
⇧ とあるので、時系列としては、
となっているので、「クレジットカード」の決済に関するセキュリティ標準（「PCI Data Security Standards（PCI DSS）」）が策定されてから暫くして管理団体（「PCI SSC (Payment Card Industry Security Standards Council)」）が結成されたということみたいね。
で、
⇧ 前回の記事で、昨今の「電子決済」は、「クレジットカード」以外にも様々な決済手段が登場しておきており、「クレジットカード」以外の対応が必要になってきていることを確認していますと。
そこで疑問となってくるのが、
一般に「カード会社」と呼ばれる企業には、VisaやMastercardなどの国際ブランドと契約して加盟店との契約や決済と精算業務を行うカード会社（アクワイアラ）と同じく国際ブランドと契約してカード会員に対してクレジットカード発行業務を行うカード会社（イシュア）の2種類があります。カード会員がカードを加盟店に提示すると、その情報は決済ネットワークを通してアクワイアラに送られ、さらにイシュアへと連携されます。この過程でカード情報が通過・処理・保存される事業者は、外部の業務委託先も含め、全てPCI DSSに準拠しなくてはなりません。
⇧ 上記サイト様によりますと、あくまで「クレジットカード」による決済にしか触れていない書きっぷりであるので、「クレジットカード」以外の決済については、「PCI DSS」に準拠する必要は無いのだろうか？という点。
「クレジットカード」を利用しない決済で、DUKPT（Delivered Unique Key Per Transaction）の利用は不要か？
もう一つ、気になるのが、
カードリーダーに施されているセキュリティ対策とは
スマートフォン決済の導入を現在検討中の事業者や加盟店、もしくは感度の高い消費者にとって、スマートフォンのイヤフォンジャックに接続するカードリーダーのセキュリティが、どのようになっているかは気になるところだろう。クレジットカード加盟店でスマートフォン決済に遭遇し、いざ自身のカードを使う際に店員の個人のスマホにカード情報が残ってしまうのではないか？そのスマホに悪意のあるアプリがインストールされていてカード番号を含む個人情報が意図せず漏えいしてしまうのではないかなど、いろいろなリスクを想定するだろう。
この点については既に標準的な暗号ソリューションにより解決されているといえる。スマートフォン決済を展開する決済事業者や、それらの事業者と包括代理契約するカード会社（アクワイヤラ）の指導により、スマホに接続するドングル型のカードリーダーにDUKPTという暗号形式が採用されている。この暗号形式を使用すれば論理的にドングルからカード情報を抜き取ったり、他のアプリから漏れたりする心配はほぼないと言える。（もちろんセキュリティに完璧はない）
“DUKPT”を利用した暗号化ソリューション
DUKPTは、Delivered Unique Key Per Transactionの略で文字通りトランザクション毎にユニークな暗号鍵を生成する仕組みである。この方式は米国ではANSI（米国工業規格） X9.24 part1として規格化されている。図の通りドングルにカードをスワイプするとDUKPTのHSM（ハードウェアセキュリティモジュール）やソフトウェアが一意の暗号鍵の生成を指示し、その鍵によって取引承認のためのカード会員データを暗号化する。暗号化されたデータが決済代行に送信され、オーソリ処理される。この仕組みを利用すれば例え悪意をもって、スマートフォンからその暗号鍵を盗んでも、次回以降の取引では別の鍵が生成され続けるため復号化することはできないということになる。
⇧ とあるので、「クレジットカード」以外の決済では、「DUKPT（Delivered Unique Key Per Transaction）」の適用は任意ってことなんですかね？
ちなみに、
DUKPTは共通鍵暗号方式で、暗号のアルゴリズムがDESやTripleDESといった一般的な共通鍵暗号方式が取られています。さらに最近は共通鍵暗号方式にAESが使われることが多いのですが、それも標準化に向けて検討されています。
安心・簡単な“カード情報非保持化”実現ソリューションのご紹介 ～PCI P2PEソリューション、非保持化ソリューションの事例～（上） | ペイメントナビ
もう1つの特徴はトランザクションごとに異なる鍵を使うことです。毎度同じ鍵を使っていると、通信を見ている人にどんな法則があるのか気づかれてしまうので、それを防ぐためにトランザクションごとに異なる鍵を使うことができます。
安心・簡単な“カード情報非保持化”実現ソリューションのご紹介 ～PCI P2PEソリューション、非保持化ソリューションの事例～（上） | ペイメントナビ
その仕組みは、シードから端末に入れる初期鍵を作りますが、初期鍵から鍵1ができる、鍵1から鍵2ができる、というかたちで100万個の鍵を作れるというものです。サーバ側がシードを持っており、端末は次から次に鍵を作って捨ててということを繰り返します。端末側には鍵は残っておらず、サーバ側がシードを持っているので、この方式でどの鍵でも作れる仕組みになっています。シードを持っていればどの鍵でも作れるので、シードを暗号保持していくことが必要であり、ここでHSMが重要になってきます。
安心・簡単な“カード情報非保持化”実現ソリューションのご紹介 ～PCI P2PEソリューション、非保持化ソリューションの事例～（上） | ペイメントナビ
DUKPTの範囲外ですが、伝送路の暗号化は規格で決まっているわけではありません。しかし、一般的にはインターネットを使う場合、VPN、SSLなどの通信暗号方式が用いられることが多く、その中をさらにDUKPTで暗号化された情報がやりとりされるイメージです。
安心・簡単な“カード情報非保持化”実現ソリューションのご紹介 ～PCI P2PEソリューション、非保持化ソリューションの事例～（上） | ペイメントナビ
また、一端末で100万個の鍵を生成できますが、100万回生成したら端末の中にある初期鍵を新しいものに交換する必要があります。その交換方法は規格に入っているわけではなく、例えば、HSMを使う場合はベンダごとに実装が異なるので、そこは新たな仕組みで行う必要があります。
安心・簡単な“カード情報非保持化”実現ソリューションのご紹介 ～PCI P2PEソリューション、非保持化ソリューションの事例～（上） | ペイメントナビ
⇧「DUKPT（Delivered Unique Key Per Transaction）」自体は、「共通鍵暗号方式」に分類されるようですが、制約が結構あるようです。
更に、「PCI Point-to-Point Encryption（PCI P2PE）」に対応する上で、「非保持化」という概念があるようで、
DUKPT・P2PEを利用した時にコンプライアンス的にはどのような有用性があるのか。加盟店における非保持化を実現するためにまず分けなさい、カード情報が加盟店のネットワークに入らないようにしなさい、という方式として外回り方式があります。これは加盟店のネットワークでカード情報の保存・処理・通過を一切させないというものです。スワイプする端末はPSP（決済処理事業者）のもので、そこでは金額と決済結果しかやり取りしないので、加盟店のPOSではカード情報の保存・処理・通過させないというかたちにすれば完全に切り離しができます。ただし、実際にそうすると、ポイントの連携システムや顧客データベースなどの一切を変えなければならないので、実現が難しい場合があります。
安心・簡単な“カード情報非保持化”実現ソリューションのご紹介 ～PCI P2PEソリューション、非保持化ソリューションの事例～（上） | ペイメントナビ
一方、内回り方式は、スワイプする端末とPOSが結び付いており、同じネットワークを使って自社やPSPのセンターにつなぎます。その時にDUKPTを利用すれば、コンプライアンス的なメリットとして、非保持と同等相当のセキュリティが確保されたと扱われ、PCI DSS準拠が必要となったときに、負担が大幅に軽減されます。
安心・簡単な“カード情報非保持化”実現ソリューションのご紹介 ～PCI P2PEソリューション、非保持化ソリューションの事例～（上） | ペイメントナビ
⇧ 上記の説明によりますと、
- 非保持化
- 外回り方式
- 内回り方式
2つの方式に分類されるようです。
6.1 必要なセキュリテュ対策内容とは
割賦販売法の改正により拡充されたクレジットカード番号等取扱業者に対するクレジットカード・セキュリティガイドラインにおけるセキュリティ対策の一覧(『クレジットカード・セキュリティガイドライン【3.0版】』P15より) 以下は抜粋した図です。
【図解付き】PCI DSSとは？準拠が必要な企業とセキュリティ対策をガイダンス | PCI DSS Ready Cloud
⇧ 上記のような違いがあるみたいですが、詳細がよく分からん...
ちなみに、
⇧ 上記サイト様で、決済処理以外にも「DUKPT（Delivered Unique Key Per Transaction）」を利用できると仰っているので、「クレジットカード」以外の決済についても、「DUKPT（Delivered Unique Key Per Transaction）」を適用できないことは無いような感じですかね。
実際に、各決済サービスが「クレジットカード」以外の決済の時に、どういう対応をしているのかは気になりますな...
決済端末を経由するような決済処理であれば、「クレジットカード」の決済の時の処理を流用できるとは思うんだけど、決済端末を経由しないECサイトのようなブラウザとかから決済する場合とかどうしてるんだろうか...
一応、
⇧「PCI SSC (Payment Card Industry Security Standards Council)」がベストプラクティス的な指針みたいなものについて言及している。
が、『Use TLS 1.1 or higher when transmitting cardholder data internally (for example, at cardholder data ingress and egress points) throughout the network per PCI DSS Requirement 4.1.』以外については、「PCI Payment Application Data Security Standard（PCI PA-DSS）」とかを参照しろってことらしいのだけど、たらい回し感が半端ないっすな...
ちなみに、GitHubで「dukpt」に関連するソースコード公開されていないか調べてみたところ、topicでの検索だと、
| No | URL | リポジトリ数 |
|---|---|---|
| 1 | https://github.com/topics/dukpt | 8 |
| 2 | https://github.com/topics/dukpt-encryption | 5 |
⇧ 全てのプログラミング言語を対象にしても、リポジトリ数が13しか無い...
GitHubの画面上部の検索欄で「dukpt」というワードで検索したところ、
⇧ ヒットしたリポジトリ数は64と。
上記で、「暗号化アルゴリズム」として「AES（Advanced Encryption Standard）」を利用しているもので「暗号化」「復号」の部分の実装は参考にさせてもらうとして、
⇧「暗号化」「復号」以外の部分の実装は、システム構成次第と言った感じですかね。
「HSM（Hardware Security Module）」に何を使っているかとか分からないと、どういう実装すれば良いか分からないと思いますし...
主要な「クラウドサービスプロバイダー」では、
⇧「HSM（Hardware Security Module）」のサービスが用意されているらしい。
クラウドベンダーに責任を負ってもらえるなら、それに越したことはないですな。
「HSM（Hardware Security Module）」のWikipediaの説明を見ると、
A hardware security module (HSM) is a physical computing device that safeguards and manages secrets (most importantly digital keys), performs encryption and decryption functions for digital signatures, strong authentication and other cryptographic functions. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server. A hardware security module contains one or more secure cryptoprocessor chips.
Uses
Card payment system HSMs (bank HSMs)
Specialized HSMs are used in the payment card industry. HSMs support both general-purpose functions and specialized functions required to process transactions and comply with industry standards. They normally do not feature a standard API.
Typical applications are transaction authorization and payment card personalization, requiring functions such as:
- verify that a user-entered PIN matches the reference PIN known to the card issuer
- verify credit/debit card transactions by checking card security codes or by performing host processing components of an EMV based transaction in conjunction with an ATM controller or POS terminal
- support a crypto-API with a smart card (such as an EMV)
- re-encrypt a PIN block to send it to another authorization host
- perform secure key management
- support a protocol of POS ATM network management
- support de facto standards of host-host key | data exchange API
- generate and print a "PIN mailer"
- generate data for a magnetic stripe card (PVV, CVV)
- generate a card keyset and support the personalization process for smart cards
The major organizations that produce and maintain standards for HSMs on the banking market are the Payment Card Industry Security Standards Council, ANS X9, and ISO.
⇧ 用途によって「HSM（Hardware Security Module）」に求められる要件も変わってくるらしい。
用途として決済を想定した場合、必要な要件が多いので、オンプレミス環境、クラウド環境のいずれで構築するにしろ、フルマネージドなサービスを利用する感じになりそうね。
つまり、オンプレミス環境であれば、「HSM（Hardware Security Module）」の機能が全て実装されたハードウェアを、クラウド環境であれば、「HSM（Hardware Security Module）」の機能が全て実装されているフルマネージドなサービスを利用する感じになるかと。
流石に、それぞれの製品、または、サービスで利用方法のドキュメントはあると思うので、APIなどが用意されていれば、APIを利用するソースコードを実装して、APIが用意されていないのであれば、フルスクラッチで実装すると。
と言っても、参考サイト様によれば、サーバーサイド側に「HSM（Hardware Security Module）」が配置される感じになるっぽいのと、あくまで、「HSM（Hardware Security Module）」に保存しておいた「BDK (Base Derivation Key)」を取り出す処理の実装が必要と言った感じになりそう。
ちなみに、
⇧ とあり、
『世界の“Contactless Payment”は「非接触IC決済」を指すが、日本のみ
「非接触＝接触しなければいいので、コード決済も非接触」と拡大解釈。
→ この感覚で各国代表者や有識者と会話すると、恥ずかしい思いをするかもしれません。』
⇧ この状態から変わっていないとしたら、日本はガラパゴス化してるっぽいですな...
本当に、この際「財務省」「経済産業省」「総務省」のどこでも構わないので、「電子決済」に関する情報について整備して欲しいですな...
本来であれば、
⇧「経済産業省」「財務省」「デジタル庁」あたりが協働して整備してくれても良い気がするんですけどね...
「デジタルトランスフォーメーション（DX：Digital Transformation）」が進まないわけですな...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
