기술 포스트
EMV 개발 가이드, 2부
이전 이 포스트의 1부에서는 EMV 거래와 그 구조에 대해 살펴보았습니다. 주요 내용은 다음과 같습니다:
- MSR(MagStripe) 거래와 달리, EMV 거래는 여러 단계에 걸쳐 진행됩니다.
- 칩 카드와 리더기 간의 대부분의 통신은 커널 수준에서 이루어지며, 애플리케이션 로직의 제어 범위 밖에 있습니다.
- 거래 결과는 TLV("태그") 형식으로 반환됩니다.
- 라이선싱 크립토그램 (카드만 알고 있는 개인 키를 사용하여 카드가 생성하는 고유한 8바이트 데이터)은 거래의 완료 단계 이전에 생성되며, 두 번째 크립토그램은 거래 완료 호출 이후에 생성됩니다.
- 암호문(cryptogram)은 태그 9F26에 담겨 카드로부터 반환됩니다(이는 ID TECH 전용 태그가 아닌 EMVCo 표준 정의 태그입니다).
일반적으로, Completion 단계를 시작하기 전에 첫 번째 암호문(및 백엔드 프로세서가 요구하는 기타 TLV 데이터)을 패키징하여 실시간으로 프로세서에 전송하고, 태그 89에 담긴 승인 코드를 받아야 합니다. 온라인 승인 요청은 리더기나 SDK가 대신 처리해 주지 않으므로, 게이트웨이의 웹 API를 활용하여 직접 수행하셔야 합니다. 대부분의 게이트웨이는 이 과정을 간소화할 수 있는 자체 SDK를 제공하고 있습니다.
게이트웨이(또는 "백엔드 프로세서")는 승인 요청에 대한 응답으로 태그 89, 8A, 91, 그리고 선택적으로 71 또는 72를 반환합니다. 거래를 완료하려면 이 TLV들을 Universal SDK의 emv_completeTransaction() 메서드에 전달하면 됩니다. 처리 결과는 콜백(callback)을 통해 통보되며, 콜백 내에서 거래 데이터 핸들을 받게 됩니다. 이 데이터에는 여러 TLV가 포함되어 있으며, 그 중에는 앞서 언급한 두 번째이자 최종 암호문도 포함됩니다. 이 암호문 역시 태그 9F26에 담겨 있습니다.
암호문(Cryptogram) 유형
태그 9F26에 반환되는 암호문은 불투명(opaque)하여 직접 검사하는 것만으로는 어떤 유형인지 판별할 수 없습니다. 그러나 9F26과 함께 반환되는 태그 9F27을 확인하면 암호문의 유형을 파악할 수 있습니다. 9F27의 상위 니블(nibble)에 필요한 정보가 담겨 있으며, 각 비트는 다음과 같이 해석할 수 있습니다(이 정보는 EMV Book 3):
일반적으로 9F27의 (16진수) 값은 80, 40, 또는 00이며, 이는 각각 ARQC, TC, AAC에 해당합니다. 이를 풀어서 설명하면 "온라인 처리 요청," "승인," 또는 "거절"을 의미합니다.
이 값들은 어디까지나 카드의 권고(advice)에 불과하다는 점을 이해하는 것이 중요합니다. 이 권고가 항상 구속력을 갖는 것은 아닙니다. 예를 들어, 카드가 필수 원래 암호문이 ARQC였으나 결제 앱이 온라인으로 연결되지 못한 경우, 두 번째 암호문(Completion 단계)에서 AAC를 반환해야 합니다. 이 경우 AAC가 자동으로 거래 거절을 의미하지는 않습니다. 최종 결정은 온라인 기관(궁극적으로는 발급사)이 내립니다. Quick Chip(또는 Faster EMV)이라고 알려진 특수 EMV 시나리오에서는 항상 AAC가 반환됩니다. 온라인 요청이 이후에 이루어지기 때문입니다. 이는 정상적인 동작입니다! 해당 거래는 여전히 정산을 위해 제출할 수 있습니다. 카드의 응답은 단순히 권고(advice)입니다. 최종 결정은 온라인 기관이 내립니다.
미국(온라인 전용 시장으로 간주됨)에서는 첫 번째 암호문에서 거의 항상 ARQC가 반환됩니다. 단, 카드가 만료되었거나 거래를 즉시 거절해야 하는 다른 사유가 있는 경우에는 예외가 적용되며, 이 경우 첫 번째 "Gen AC" 요청 이후에 AAC가 반환될 수 있습니다(이론적으로).
TLV 데이터 조회
Universal SDK는 USB, RS-232, Bluetooth, 오디오 잭 또는 이더넷(리더기 유형에 따라 다름)을 통해 ID TECH 리더기와의 통신을 대신 처리합니다. 이 SDK에서 리더기와 주고받는 모든 거래 관련 통신은 비동기 방식으로 이루어지므로, 리더기로부터 응답을 받으려면 SDK에 하나 이상의 커스텀 콜백 루틴을 등록해야 합니다. 이에 대한 안내는 SDK 문서뿐만 아니라 SDK에 포함된 샘플 코드에서도 확인할 수 있습니다. 콜백 사용 방법은 어렵지 않습니다. SDK의 샘플 코드를 통해 전체 흐름을 충분히 파악해 보시기 바랍니다.
중요한 점은 EMV 거래가 단계별로 진행되며, 각 단계가 끝날 때마다 서로 다른 TLV 데이터가 반환된다는 것입니다. 흔한 오해 중 하나는 Completion 단계가 끝나면 필요한 모든 태그를 한꺼번에 받을 수 있다는 것인데, 이는 사실이 아닙니다. TLV 데이터는 각 단계에서 수집해야 합니다.
각 단계에서 어떤 태그를 받을 수 있을까요? 거래 단계별로 가장 일반적인 태그는 다음과 같습니다.
거래 시작:
4F
50
57
5A
5F20
5F24
5F25
5F2D
5F34
84
9F20
DFEE12
DFEE23
거래 인증:
95
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
완료된 트랜잭션:
95
99
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
9F5B
이 항목들의 대부분은 업계 표준으로 정의된 EMVCo 태그입니다. 'DF'로 시작하는 태그는 ID TECH 고유 태그입니다. ID TECH 고유 태그와 그 의미에 대한 전체 목록은 문서 80000503-001, ID TECH TLV Tag Reference Guide를 참조하시기 바라며, 해당 문서는 당사 기술 자료.
필요한 태그가 보이지 않으십니까? 문제없습니다. Universal SDK를 사용하여 트랜잭션 시 추가 태그를 요청할 수 있습니다. 이에 대한 자세한 내용은 SDK 문서뿐만 아니라 당사의 백서에서도 확인하실 수 있습니다: EMV Transactions with the Universal SDK.
어떤 태그가 암호화됩니까?
리더기에 키 주입이 완료되고 암호화가 활성화된 경우, 민감한 데이터가 포함된 태그는 그 내용이 암호화됩니다. 여기에는 트랙 데이터(예: 태그 57)나 PAN 데이터(5A)가 포함된 태그가 해당됩니다. 암호화된 태그의 전체 목록은 문서 80000502-001-F, ID TECH Encrypted Data Output. 데모 유닛(데모 키가 주입된 장치)을 사용 중이라면, 당사의 온라인 도구를 통해 데이터를 직접 복호화할 수 있습니다. 다만 일반적으로 실제 프로덕션 코드에서는 데이터를 프로세서에 바로 전달하게 되므로, 직접 복호화할 필요가 없습니다.
암호화는 방대한 주제입니다. 지금 당장 자세히 다루지는 않겠지만, 관심이 있으시다면 이 주제를 다룬 당사의 이전 게시물 을 참고하시기 바랍니다.
궁금한 점이 있으신가요?
지금쯤 많은 궁금증이 생기셨을 것입니다. 걱정하지 마세요! 당사 기술 자료에서 다양한 무료 리소스를 이용하실 수 있으며, 그래도 궁금한 점이 남아 있다면 전화 한 통으로 기술 담당자와 바로 연결하실 수 있습니다.