EN

NRIセキュア ブログ

PCI MPoCとは?対面決済の新たなセキュリティ基準を徹底解説

目次

    blogtop

    市販のスマートフォンやタブレットなどのCOTS*1デバイスを店頭の決済端末として利用する決済ソリューションが近年、注目を集めている。PCI MPoCとは、これらの決済ソリューションのセキュリティ基準のことである。

     

    PCI SSC*2はこれまで、2018年1月にPCI SPoC(Software-Based PIN Entry on COTS)を、2019年12月にPCI CPoC(Contactless Payments on COTS)をリリースしてきた*3そして、2022年11月、これらの基準をベースにPCI MPoC(Mobile Payments on COTS)という新たなセキュリティ基準がリリースされた。本稿ではPCI MPoCで導入された変更点や特徴について解説する。

     

     

    *1 COTSとはcommercial off-the-shelfの略で、COTSデバイスは一般消費者向けに販売されているスマートフォンやタブレットなどを指す。

    *2 PCI Security Standards Councilの略で、クレジット決済全般のセキュリティ基準の開発、管理、教育、および認知を担当する機関。

    *3 PCI SPoC、PCI CPoCの詳細については以下の過去記事を参照。

     

    COTSデバイスを活用したキャッシュレス決済の新潮流|新たなセキュリティ基準が登場

     

    対面決済のニューノーマル|クレジットカードの「非接触決済」を徹底解説

     

     

    NRI Secure Insight 2023

     

    PCI MPoC誕生の背景

    COTSデバイスを店頭の決済端末とするソリューションのセキュリティ基準としてはPCI SPoCとPCI CPoCが既にリリースされていた。PCI SPoCでは、COTSデバイス上の専用ソフトウェアでPIN(暗証番号)入力を受け付けることができるが、クレジットカードの読み取り自体は外付けの専用リーダーであるSCRP(Secure Card Reader for PIN)というデバイスで受け付けることを前提としている。

     

    一方のPCI CPoCでは、COTSデバイスのNFC(近距離無線通信)を利用してカード情報を読み取ることができるが、PIN入力をCOTSデバイスの専用ソフトウェアで受け付けることは禁止していた。

    PCI SPoC、PCI CPoC、PCI MPoCの利用イメージ図図1:PCI SPoC、PCI CPoC、PCI MPoCの利用イメージ図(NRIセキュアが作成)

     

    PCI SPoCとPCI CPoCでは共通するセキュリティ要件が多いこともあり、1つのセキュリティ基準であらゆる決済手段に対応できるセキュリティ基準を策定することが、PCI MPoC策定にあたっての一つの大きな動機付けであったと思われる。

     

    それでは、PCI MPoCがこれまでのPCI SPoCやPCI CPoCと比べて、具体的にどのように変わったのか詳しく解説していく。

    サポート範囲の拡大

    PCI MPoCでは、サポートされるカード情報の読み取り方法やCVM(Cardholder Verification Methodの略。クレジット決済におけるPIN入力などの本人確認方法を指す)が拡大された。以下が、PCI MPoCでサポートされているカード情報の読み取り方法とCVMの一覧となる。

    カード情報の
    読み取り方法

    COTSデバイスのNFCインターフェースでの読み取り

    ※タッチ決済などの非接触型ICカードのみ対応可能

    PCI PTS認定の外付けのSCRPデバイスでの読み取り

    ※タッチ決済などの非接触型ICカードに加え、接触型ICカードや磁気カードの読み取りにも対応可能

    外付けのMSR *4での読み取り

    ※読み取りデバイスがPCI PTS認定されていない場合は、PCI MPoCのAppendix E「MSR Security Requirements」に記載のセキュリティ要件に従って評価が必要

    手動でのカード情報の入力

    CVM

    COTSデバイス上の専用ソフトウェアでのPIN入力

    No CVM *5

    CDCVM *6

    表1:PCI MPoCでサポートしているカード情報の読み取り方法とCVM

     

     

    *4 Magnetic Stripe Readerの略で磁気ストライプカードリーダーのことを指す。

    *5 クレジットの対面決済において本人確認不要で取引を行う方法。

    *6 Consumer Device CVMの略。Apple PayやGoogle Payなどのスマートフォン決済において、消費者自身のデバイス側で指紋や顔認証のような本人確認を実施して取引を行う方法。

    PCI MPoCにおける全体概要図図2:PCI MPoCにおける全体概要図

     

    PCI MPoC認定のソリューションでは、以下の前提条件に合致していれば、これら全ての機能を認定対象に含めてサポートする必要はなく、柔軟に取捨選択することが可能となっている。

     

    • <前提条件>
    • ・接触型ICまたは非接触型ICのクレジット決済での支払いに対応していること。
    • かつ
    • ・「COTSデバイスのNFCインターフェースでのカード情報読み取り」、または「COTSデバイス上の専用ソフトウェアでのPIN入力の受付」のいずれか1つ以上に少なくとも対応していること。

     

    PCI MPoCでは、COTSデバイスだけでカード情報読み取りとPIN入力の処理を同時に行うことも、セキュリティ要件を満たせば可能となっている。この点は、外付けの専用カードリーダーでのカード情報の読み取りが必要であったPCI SPoCや、PIN入力自体を禁止していたPCI CPoCとは大きく異なる点と言える。

     

    また、従来のPCI SPoCのように外付けのSCRPデバイスでカード情報を読み取り、COTSデバイス上の専用ソフトウェアでPIN入力を受け付けることもPCI MPoCのサポート範囲として含むことも可能である。その一方で、磁気カード読み取りやマニュアルでのカード情報入力しかサポートしていないなど、上述の前提条件に合致しないケースの場合にはPCI MPoCの認定対象外となる。

     

    PCI MPoCのセキュリティ要件は大きくDomain1からDomain5と、Appendix 要件から構成されているが、サポートするカード情報の読み取り方法や、COTSデバイス上の専用ソフトウェアでのPIN入力の受付の有無によって、対象となるPCI MPoCのセキュリティ要件が異なる。

     

    具体的には、Module 1D「Secure Entry and Processing of Account Data」の要件がカード情報の読み取り方法によって対象要件が一部異なる。また、COTSデバイス上のPIN入力のサポート有無によってModule 1E「PIN Entry on COTS Device」のセキュリティ要件の対象要否も変わってくる。

    PCI MPoCのセキュリティ要件の概要

    表2:PCI MPoCのセキュリティ要件の概要

    柔軟になったソリューション認定

    これまでのPCI SPoCとPCI CPoCでは、1つのソリューションプロバイダーが認定対象となっていたが、PCI MPoCでは「MPoC Software Vendor」、「Attestation and Monitoring Service Provider」、「MPoC Solution Provider」の三つの事業体に分類され、それぞれが提供するコンポーネントを組み合わせることでPCI MPoC認定を取得することが可能となった。

     

    各コンポーネントをMPoCソリューションに組み込むにあたっては、PCI SSCによって事前に認定されたコンポーネントに限られるが、認定済みのコンポーネントを利用することによって、これまで以上にソリューション認定を簡単かつ柔軟に取得できるようになったと言える。

     

    例えば、既にPCI MPoC認定済みの「MPoC Software」と「Attestation and Monitoring Service」を組み合わせれば、それぞれのコンポーネントでカバーしている要件は対象外としたうえで、「MPoC Solution Provider」だけに必要な要件に絞ってPCI MPoCのソリューション認定を取得することができる。

     

    MPoC Software Vendor

    COTSデバイス上でカード情報を読み取るソフトウェアや、PIN入力を受け付けるソフトウェア、バックエンドシステム側のソフトウェアなどの開発、配布、サポートを行う事業体。PCI MPoCの「Domain 1:MPoC Software Core Requirements」のセキュリティ要件を満たす必要がある。

    Attestation and Monitoring Service Provider

    アテステーション(検証)やモニタリングを行うバックエンドシステムの運用サービスなどを提供する事業体。PCI MPoCの「Domain 3:Attestation and Monitoring」のセキュリティ要件を満たす必要がある。

    MPoC Solution Provider

    MPoCソリューションの実装と管理に対する全体的な責任を持つ事業体。

    表3:三つの事業体分類

    PCI MPoCで追加されたセキュリティ観点

    カード情報の読み取り方法やCVM、認定スキームにおける柔軟性の向上が、これまでのPCI SPoCやPCI CPoCとは異なる大きな変更点であり、PCI SSCのプレスリリースや公式ブログ、「2022 Asia-Pacific Forum」といったイベントなどでもこの2点については言及されていた*7

     

    それ以外に、筆者が今回リリースされたPCI MPoCセキュリティ基準を読んで個人的に興味深いと感じた変更点を以下に記載する。PCI MPoCのセキュリティ要件の内容はPCI SPoCとPCI CPoCを踏襲した内容となっているものの、下記で述べた点以外にも違いはあるため、あくまでも主だったものだけであることにご留意頂きたい。

     

     

    *7 PCI SSCのPCI MPoCに関するプレスリリース、公式ブログ、フォーラムは以下。

    1.オフライン決済への対応

    従来のPCI SPoCとPCI CPoCでは、バックエンドシステム側のA&Mシステム(アテステーションとモニタリングのシステム)でCOTSデバイスやアプリケーションの状態を監視し、異常がないことを確認した上ではじめて取引ができる仕組みとなっていた。つまり、バックエンドシステムとの通信環境が決済取引ごとに担保されていることが前提になっていた。

     

    一方、PCI MPoCではバックエンドシステムとのオフライン状態(オフラインモード)が条件付きで認められるようになり、一時的な通信不良などのケースにおいても取引を継続できる可能性が出てきた。このオフライン決済のサポートはPCI MPoCでは必須要件ではないが、仮にこの機能をサポートする場合はPCI MPoCの「Module 1F:Offline Payment Transactions」のセキュリティ要件に従う必要がある。

     

    Module 1Fのセキュリティ要件としては例えば、オフラインモードは最大48時間までの継続動作しか認めないことや(PCI MPoCセキュリティ要件1F-1.4)、COTSデバイスの再起動後に一度もA&Mシステムに接続していない状態でのオフラインモードは禁止することなどがある(PCI MPoCセキュリティ要件1F-2.1)。

     

    これ以外にも様々な追加のセキュリティ要件があるが、これらの要件はどれも、オフラインモードでも安全に決済できるように考慮された結果から追加されたものとなっている。

    2.PCI Secure Software Standardへの対応

    PCI MPoCでは、SCRPのPCI PTS認定や、バックエンドシステムのPCI DSS準拠など、他のPCI基準への対応が前提となっている。基本的には、PCI SPoCとPCI CPoCで求められていた内容と大きく相違はないが、バックエンドシステム側のA&Mコンポーネントのソフトウェアに関して、PCI Secure Software Standardへの準拠が求められるようになっている点が大きな違いとなっている(PCI MPoCセキュリティ要件1A-1.4)。

     

    またこれ以外にも、「MPoC Software」については、PCI Secure Software Lifecycle(SLC)認定を受けたソフトウェアベンダーによって開発されるか、またはPCI MPoCの「Appendix D:Software Security Lifecycle Requirements」に記載の全要件に対応しなければいけない、といった要件内容となっている(PCI MPoCセキュリティ要件1A-1.1/2B-1.1)。

     

    PCI SPoCとPCI CPoCでもアプリケーションの開発プロセスに関する要件はあったものの、PCI Secure Software Lifecycle(SLC)に言及する記載はなく、PCI SPoC/PCI CPoCの「Appendix D:Software Security Requirements」の内容に従う旨の記載だけとなっていた。

     

    このように、PCI Secure Software StandardとPCI Secure Software Lifecycle(SLC)を意識した内容となっている点も、PCI MPoCの新たな特徴と言える。

    対象デバイス/システム

    必要となる認定や評価項目

    外付けデバイスのSCRP

    PCI PTS POI

    ※磁気カードリーダーに限り、PCI PTS認定されていない場合でもPCI MPoCの「Appendix E : MSR Security Requirements」に記載の要件に対応することで代用可能

    バックエンドシステムのカード情報を処理するシステム

    PCI DSS

    バックエンドシステムのPIN情報を処理するシステム

    PCI PINセキュリティ

    バックエンドのA&Mシステム

    PCI DSS DESV*8

     

    ※カード情報などのアカウントデータと分離されている場合は、PCI MPoCの「Appendix A:Back-end Environment Security Requirements」に記載の要件に対応することでも代用可能

    PINやカード情報を復号するバックエンドシステムのHSM

    PCI PTS HSMまたは

    FIPS 140-2/140-3 Level3以上

    A&Mコンポーネントのソフトウェア

    PCI Secure Software Standard

    MPoC Software

    PCI Secure Software Lifecycle(SLC)

    ※PCI MPoCの「Appendix D:Software Security Lifecycle Requirements」に記載の要件に対応することでも代用可能

    表4:PCI MPoCで前提となる外部基準や評価フレームワーク

     

    *8 DESVはDesignated Entities Supplemental Validationの略で、以下のようなケースにおいて、PCI DSS の通常の要件(要件1~要件12)とは別に、PCI DSS の「付録A3: 指定事業体向け追加検証(DESV)」に記載の追加要件の検証が必要となることがある。

    ・カード会員データを大量に保存、処理、および/または伝送している。

    ・カード会員データの集約場所を提供している。または

    ・カード会員データの重大な、または度重なる侵害を受けたことがある。

    3.Cloud HSM利用に関する要件

    カード情報やPINの保護に使用する暗号鍵の保護に関してHSMを使用する要件は、PCI SPoC/PCI CPoCから既にあったが、CloudベースのHSMの利用に関するセキュリティ要件はPCI MPoCが初めてとなる。

     

    PCI MPoCのセキュリティ要件4A-2.4でCloudベースのHSMの使用について言及されており、「バックエンドシステムにCloudベースのHSMを使用する場合、暗号鍵は関連するMPoC事業体によって管理し、クラウド事業者からアクセスできないようにすること」と明記されている。Cloud ベースのHSMの利用が明示的に許容されている一方で、その利用については暗号鍵を事業体自身で管理することを厳格に求めていると言える。

     

    CloudベースのHSM、と一口にいっても様々なサービス提供形態がある中で、鍵の生成・管理まで全てクラウド事業者側に実質的に委ねるような利用方法はPCI MPoCでは認められておらず、クラウド事業者側に鍵管理を委ねずにクラウド利用者側の責任で鍵の生成・管理を実施することが前提となっている。

     

    これは、例えばクラウドベースの鍵管理の構成の1つの考え方であるHYOK(Hold Your Own Keyの略。暗号鍵の管理をクラウド事業者側ではなく利用者自らが実施する方式)などを前提としたシステム構成を検討する必要がPCI MPoCではあるのではと筆者は考える。

    さいごに

    PCI MPoCは、PCI SPoCとPCI CPoCをベースとして2022年11月にリリースされた新しい基準である。サポートされるカードの読み取り方法やCVMが拡大されており、また認定対象の事業体が「MPoC Software Vendor」、「Attestation and Monitoring Service Provider」、「MPoC Solution Provider」の三つの事業体に分類されることで、認定スキームの柔軟性も大幅に向上した。

     

    COTSデバイスだけでカード情報の読み取りとPIN入力に対応できるようになったことに加え、オフライン決済にも対応しており、多種多様な決済シーンにも対応できる新しいセキュリティ基準になったと言える。

     

    今後は、まずは既存のPCI SPoCやPCI CPoCの認定ソリューションプロバイダーが、既存の仕組みをベースにPCI MPoC認定を取得するのではと考えられる。その際、一つのモノリシックなサービスとして認定取得するだけではなく、「MPoC Software」用のSDKやアプリケーションも個別に認定取得したり、「Attestation and Monitoring Service」だけでPCI MPoC認定を取得したりすることも考えられる。

     

    これらの認定済みコンポーネントを組み合わせることで、新規のソリューションプロバイダーも次々と登場するかもしれない。今後、多種多様なPCI MPoC認定のソリューションが誕生し、COTSデバイスを利用した安全・安心な対面決済が幅広く利用されるようになることを期待したい。

     

     

    新規CTA