技術記事
EMV対応開発 第1回
ID TECHは多種多様な決済デバイスを製造・販売しており、現在ではそのほぼすべてが「ICカード」（または「スマートカード」）に対応しています。ICカードによる決済は一般に「接触EMV」、あるいは単に「EMV」と呼ばれます。（もちろん、EMVはEuropay、MasterCard、Visaの頭文字で、カードブランド連合を指します。）
業界用語としてのEMVトランザクションとは、全4巻からなる次の仕様書の要件に準拠した取引を指します。 決済システム向けEMV ICカード仕様 （入手先： https://www.emvco.com/）。この仕様の全体像を把握するには時間がかかります。全4巻という、非常に広範な仕様だからです。とはいえID TECHでは、開発者が「EMV対応」という目標に容易に到達できるよう、無料のツール類、SDK、デモ、その他のリソースを各種提供しており、迅速な対応を必要とするPOSインテグレーターなどの市場投入までの時間短縮を支援しています。 EMV準拠.
EMV：どこから始めるべきか？
ID TECHの新規のお客様の多くは、技術面に非常に精通しています。とはいえ、新しいプロジェクトに持ち込まれるEMVの知識レベルには、大きなばらつきがあります。MSR（磁気ストライプリーダー）の文脈であれば、ほとんどのお客様が決済システムを熟知しています。EMV自体の経験はあっても、次のような分野はご存じない方もいます。 非接触 EMV。一方で、EMVそのものが初めてという方もいらっしゃいます。
参考資料として、インテグレーターの方々には、ID TECHが無償で提供している以下のホワイトペーパーをご覧いただくことをお勧めしています。 Universal SDKを使用したEMV取引。この25ページのホワイトペーパーの前半部分は、EMVイベントフローの復習となっています。そのフローの主要なイベントは、次のようにまとめることができます。
このプロセスの各段階で、カードリーダーはISO-7816で定義された非常に低レベルのプロトコルを用いて、スマートカード上のICチップと通信します。この通信に関わるカードリーダーのロジックのほぼすべては、いわゆる以下の部分に隔離されています。 EMV Level 2カーネル。つまり、決済アプリの開発者が直接触れることはできず、開発者が考慮すべきことは、コマンドを以下に発行することだけです。 カーネル （カード自体ではなく）。とはいえ、これもやや不正確な表現です。実際には、決済アプリの開発者がコマンドを送る先は、以下になります。 リーダーであり、そのリーダーがカーネルとの必要な低レベルのやり取りを処理し、カーネルが（さらにその先で）カードとやり取りします。
リーダーとの通信
リーダーへコマンドを送るには、どうすればよいのでしょうか。選択肢は2つあります。
- リーダーと（通常はUSBまたはRS-232を用いて）接続を確立し、ファームウェアコマンドを直接送信する。あるいは、
- 高水準言語のSDKを使用し、適切なID TECHのSDKライブラリを活用するコードを（C/C++、C#、Objective-C、Java、またはSwiftで）記述し、その内部でファームウェアコマンドを発行する。
2番目の方法のほうが一般的に容易です。ID TECHのUniversal SDKの高水準言語APIを習得するのに比較的時間がかからず（さらに、土台にできるサンプルコードも豊富に提供しています）。一方、 デメリット として、方法2ではアプリが特定の開発言語およびOSに縛られやすくなる傾向があります。方法1なら、言語（およびOS）の選択は自由ですが、対象デバイスの（バイトレベルの）ファームウェアコマンドAPIを習得し、接続性に関する諸問題もすべてご自身で処理する必要があります。
カードリーダーと直接通信する方法（シリアル接続を介し、生のファームウェアコマンドを使用する方法）を選ぶか、それともUniversal SDKの組み込みの接続機能や高水準コマンドを使う方法を選ぶかにかかわらず、EMVトランザクション（ここでは従来の 接触 EMVを指し、非接触ではありません）が3つの段階で進行することを理解しておくことが重要です。Universal SDKの用語では、これらの段階を Start Transaction、Authenticate Transaction、Complete Transaction と呼びます。（それぞれにUSDK内で対応するメソッドまたは関数があります。）プログラムフローの観点でいえば、これはトランザクションフローの途中で、カーネルが呼び出し元に制御を2回返すことを意味します。1回目は Start Transaction の終了後、2回目は Authenticate Transaction の終了後（ただし Complete Transaction の前）です。これらの停止点はデータフローに重要な影響を及ぼします。なぜなら、各トランザクション段階の終了時に返されるTLV（タグ・長さ・値の組）は異なり、必要なTLVは取得可能なタイミングで取得しておく必要があるからです。後の段階では取得できなくなる場合があります。代表的な例として、Tag 57（Track 2 データ）は Start Transaction の終了時には取得できますが、Complete Transaction の終了時には取得できません。
EMVにおける暗号文（クリプトグラム）
EMVトランザクションにおいて最も重要なデータ項目のひとつが、次のタグで返されるアプリケーション・クリプトグラムです。 9F26。接触EMVセッションでは、通常2つのクリプトグラムが生成されます（9F26 は2回返されます）。一方は Complete Transaction の前に、もう一方はその後に取得されます。カードに対してクリプトグラム生成を促すイベントは、Gen AC（Generate Application Cryptogram）リクエストと呼ばれます。
これらのクリプトグラムが重要なのは、当該トランザクションにおいて、本物かつ正規のICカードが物理的に提示されていたことを否認不能な形で証明するものだからです。（また、そのトランザクション中に発生した具体的なデータ値も保証します。）Gen AC の時点で、L2カーネルはICカードに対し、 データオブジェクトリスト （当該トランザクション固有のデータを含む）を提示します。ICカードはこれに対し、ICチップ内のみに保持される秘密鍵を用いてそのデータに署名し、偽造不能なデジタル成果物（8バイトのクリプトグラム）を生成して応答します。これにより、カードおよびデータの正当性が証明されます。クリプトグラムの正当性は、最終的にそのトランザクションを承認（または条件により拒否）するオンラインの権限機関によって検証可能です。 これこそが、ICカードが発明された理由であり、EMVが存在する理由です。磁気ストライプのデータは容易に偽造できます。しかし、ICチップによってオンデマンドで生成されるクリプトグラムは、簡単に偽造することはできません。
次回の投稿では、カードが生成できる暗号文の種類、その意味、決済アプリ開発者が行うべき処理、そしてそれらが取引の成否にどう影響するかを引き続き見ていきます。Part IIをお見逃しなく！
EMV取引、カードリーダー、非接触技術、デジタルウォレットについてご質問はありませんか？当社の専門家までお問い合わせください：