Payment Specialist Interview Prep

Generic Job Responsibilities:

Payment Tech specialist (Interac Corp.)

Performing the technical support functions

Debit products and services, including Mobile payment projects.

Reviewing functional, security and design specifications to ensure full understanding of what a particular organization is trying to accomplish.

Analyzing external specifications and provide technical translations to the internal team to consume.

Developing, enhancing and maintaining technical specifications

Review architecture and design, recommending an appropriate framework, creating automation scripts, review deployment plans, support internal teams and partners for deployment activities, work with internal teams for defects triage and resolution.

Technical Payments specialist role is responsible for working with Product to plan development and delivery roadmaps for Interac Debit.

Knowledgeable in EMV payments and API software testing.

Payment system explained on Stripe's Website

The customer: the individual or entity that initiates the payment for goods or services.

• The merchant: the business or service provider that accepts the payment from the customer.

• The payment method: the method that the customer uses to make the payment, such as credit cards, debit cards, electronic wallets or cryptocurrencies.

• The point-of-sale (POS) system: the physical or digital platform where the transaction takes place, such as a retail terminal, e-commerce website or mobile app.

• The payment gateway: a service that securely captures and transmits payment information from the POS system to the payment processor or acquiring bank, ensuring the encryption and security of sensitive data during the transaction process.

• The payment processor: a third-party company that handles the technical aspects of the transaction, including validating payment information, obtaining authorisation and managing communication between the acquiring and issuing banks.

• The acquiring bank, or acquirer: the financial institution that holds the merchant's account, receives the payment on its behalf, processes the transaction and settles the funds in the merchant's account.

• The card network: organisations (e.g. Visa, Mastercard and American Express) that establish the rules, standards and infrastructure for processing transactions, using their branded payment instruments.

• The issuing bank, or issuer: the financial institution that has issued the payment instrument to the customer and is responsible for authorising or declining the transaction, based on the customer's account status, available funds and other factors.

• Payment security: technologies and standards, such as the Payment Card Industry Data Security Standard (PCI DSS), tokenisation or encryption, that ensure the safety and integrity of payment information and protect against fraud and data breaches.

• Settlement and reconciliation: the process of transferring funds between the issuing bank and the acquiring bank, followed by updating the merchant's account and generating transaction records for both the customer and the merchant.

Payments and EMV Certification Specialist:

• Conduct hands-on EMV certification tests for Terminal devices, assist Stripe users and partners with EMV certifcations to allow them to on-board devices

• Work closely with the payments networks to negotiate and clarity specifications, and engage with industry leaders like EMVCo on Stripe's behalf.

• Work closely with engineering teams to diagnose and fix EMV tag, host, certifiation and payments realted issues.

Specific tasks to perform:

• Conduct hands-on EMV certification tests for Terminal devices.

• Assist Stripe users with EMV certifications to allow them to on-board devices.

• Coordinate with Third-party vendors and contractors on certification planning and execution.

• Work closely with network partners to negotiate and clarify specifications.

• Participate in industry events and conferences to shape payments industry policy decisions and inform the Stripe and Terminal roadmap

• Work closely with engineering teams to diagnost and fix EMV certification-related issues.

• Work closely with engineering teams to help increase efficiency and automate processes.

Qualifications:

• 3+ years of experience performing either host certifications or terminal EMV device certifications.

• A good understanding of payments standards and concepts and know how to find and understand the specifications.

• Experience with at least one of the following certification tools: UL/Collis, FIME/Savvi, ICC.

• Experience working alongside software engineers and payment partners.

• Experience working with EMVCo, ISO, or ANSI standards.

• Excellent interpersonal and communication skills; ability to manage priorities across a large number of teams, clearly communicate status, and remain focused under pressure.

---

The three levels of EMV certification ensure that payment devices and software adhere to EMV standards, from the hardware level (Level 1) to the software components (Level 2) and the integration with payment applications and networks (Level 3).

• Level 1 certification is the responsibility of the device hardware supplier

• Level 2 certification is the responsibility of the device software supplier

• Level 3 testing ensures the conformity of merchant terminals to payment systems policies and procedures.

  
  

---

GSTP is a developer sandbox and the tool to complete certifications

• Create custom test scripts that includes EMV test scripts and allows the dev to perform unattended testing and view the results with details of any coding errors.

B2 CIT

• Used to test Gateway and middleware solution

Collis Merchant Test Suite

• Provides true card simulation by emulating all the functions of an actual EMV chip

Collis Card Spy

• Gives you the ability to trace, capture and analyse a transaction between a device (POS) and an actual EMV card

ICC Solutions:

• Another EMV test tool that majorly uses Merchant test cards to test terminal configuration and ensure that is accepts and returns the correct responses.

Fime/Savvi:

• A single tool for faster, simpler brand terminal certifications

• Acquirers and merchants who deploy new EMV terminals must test and certify in line with multiple brand requirements

• Savvi Test Platform significantly reduces the time needed to successfully complete L3 terminal intergration testing

---

The EMV POS Application sends a Generate Application Cryptogram (AC) command to the PIN pad to start card action analysis. Specifies whether or not a CDA signature is being requested.

---

Decision to -

1. Decline the transaction by requesting an Application Authentication Cryptogram (AAC). An AAC is used to terminate the transaction with the card

2. Approve the transaction offline by requesting a Terminal Certificate (TC)

3. Process the transaction online by requesting an Application Request Cryptogram (ARQC). Pre authorization requests are always performed online.

The above provides the transaction data needed by the card to perform Card Risk Management and calculate the cryptograms.

---

The EMV chip application responds to the PIN pad with the card decision, which must comply with the following rules:

1. If an AAC was requested (decline), the card must respond with an AAC

2. If an ARQC was requested (approve online), the card may respond with an ARQC or with an AAC

3. If a TC was requested (approve offline), the card may respond with a TC, an ARQC or AAC

---

PIN pad response contains: -

• Cryptogram Information Data (TAG 9F27)

• Application Transaction Counter (TAG 9F36)

• Application Cryptogram (TAG 9F26)

• Optionally the Issuer Application Data (TAG 9F10)

---

More About Cryptography:

RSA key Cryptography (Longer Key length, enough security, but transaction processing speed and technical function of the kernel might be impacted) replaced by ECC in 2021 (Elliptical Curve Cryptography) Shorter key length, robust security and durability for terminal technical function (RF) etc.

The central processing systems of issuers, acquirers, and payment networks make up the core of payment systems.

---

A payment system is an operational network which links bank accounts and provies for monetary exchange using bank deposits.

Some payment systems also include credit mechanisms, which are essentially a different aspect of payment.

Triple DES algorithm:

Triple Data Encryption Standard (Triple DES) is a symmetric block cipher-based cryptography standard that uses fixed length keys with three passes of the DES algorithm. As a symmetric cryptographic scheme, DES implementations rely on the same secret keys shared between the sender and the recipient.

Triple DES was developed as a way to prevent man in the middle attacks.

Encryption keys need to be protected against a confidentiality, integrity or availability (CIA) compromise common in a Man in the Middle attack. As such, multiple rounds of encryption and decryption rounds are implemented with the Data Encryption Standard (DES) algorithm.

The Encryption scheme can be denoted as:

• C(x) = EK3(DK2(EK1(P(x))))

• Encrypt plaintext using the key K1; decrypt using key K2 and encrypt the resultant using K3.

And the Decryption scheme can be denoted as:

• P(x) = DK3(EK2(DK1(C(x))))

• Decrypt the plaintext using the key K1; encrypt using key K2 and decrypt the resultant using K3.

Where:

• P(x) is the plaintext

• C(x) is the ciphertext

• EK is the encryption using a key K

• DK is the decryption using a key K

Online Pin:

• Pinpad encrypts the PIN with TDES public key technology

• Nothing gets transmitted to chip on the card

• Encrypted online pin is sent to Card Issuer, where it is decrypted

• Card issuer compares the cardholder-entered PIN stored securely on their system

Offline Plaintext (Clear Text PIN):

• PINPAD prompts the cardholder for a PIN

• PIN in cleartext format goes to the chip on the card in the clear

• Nothing is sent to the Card Issuer

• The card compares the entered PIN to the reference PIN stored secretly in the chip

Offline Enciphered PIN:

• PINPAD encrypts the PIN with public key technology

• PIN goes to the card where the card decrypts it

• Nothing is sent to the card issuer

• The card compares the entered PIN to reference PIN stored secretly in the chip

Signature:

• Cardholder signs the transaction receipt

• Nothing is transmitted to chip

• Nothing is sent to card issuer

• Merchant compares this signature to the signature on the card

Preparation Notes:

The issuer, or the issuing bank or card issuer, represents the customer in a transaction. The issuing bank is the financial institution that supplies an individual with the payment card they use to initiate a transaction. An issuer can be a bank, credit union or other financial institution.

Visa, Mastercard, Discovery, or American Express are the companies that provide the networks that process payment card transactions; they are not involved in individual transactions or payments. 

The issuer and acquirer handle a given transaction.

In these transactions, the issuer takes on the risk of issuing credit to an individual.

If the issuer represents the customer in the transaction, the acquirer, also called the acquiring bank, represents the business. Acquirers are banks or financial institutions that provide a company with the tools needed to collect payment from issuers.

Acquirers literally acquire money from the issuer and ensure that it is deposited into the business’s account, allowing the transaction to be processed and completed. They also provide the business with a unique ID that allows them to communicate with card networks to complete these transactions.

The acquirer routes the money that the issuer provides to the correct merchant account.

Like issuers, acquirers also carry some financial risk. They are responsible for implementing security standards that meet the requirements of the Payment Card Industry Data Security Standards Council. Failing to do so increases a bank’s liability in the event of a data breach or of information or cardholder data being stolen and used for malicious purposes during a transaction.

With a chargeback, the acquirer is liable for repaying the issuer, which will return the funds to the customer. This carries a cost for the acquirer associated with the internal resources required to review chargeback requests as well as fulfilling them. To do so, an acquirer may maintain a reserve account from which to issue chargebacks or offer a line of credit to the business to cover these costs. If a business becomes insolvent and is unable to pay back the acquirer, the acquirer must accept the loss.

What is the difference between an acquirer and an issuer?

Issuers maintain the debit or credit accounts of a cardholder, offering cardholders access to their money or a line of credit that can be used to make payments through a card transaction, while acquirers take that money and deposit it into a business’s account at the same time as maintaining records of transactions and forwarding any authorisation request to the relevant card network.

Here’s how these banks work together during a transaction:

• The customer initiates a payment by swiping or tapping their card at a point of sale (POS) terminal, such as Stripe Terminal.

• The business’s payment-processing provider (Ingenico, Square or Clover) sends the transaction information to the acquirer (Global Payments), which submits it to the card networks (MC, VI, DI, AX)

• The card networks process the request and ask the issuer RBC if the funds are available. After examining the cardholder's accounts, the issuer approves or declines the request.

• That information is sent to the card network, which sends the approval or decline notice to the acquirer, which informs the business about the transaction's status.

• If approved, money moves from the issuer to the acquirer to be deposited in the merchant account.

While the above example concerns a one-off, in-person transaction that takes place at a POS terminal, the working relationship between issuers and acquirers remains the same when the transaction is a recurring one, as in the case of a monthly subscription. 

These billing options also require close communication between the issuer and acquirer, but are initiated automatically based on an approved recurring transaction. A provider like Stripe can manage these different types of billing options for businesses.

In the case of a chargeback, the roles of the acquirer and issuer are reversed. 

A cardholder initiates the refund request and submits evidence that a refund should be issued to their card issuer RBC . The issuer RBC  reviews that information and decides whether or not to process a chargeback. 

If approved, the issuer RBC requests the return of funds from the business JJ by communicating the dispute with the acquirer GP . The acquirer reviews the request and issues the chargeback, which the business must then pay for, either through a reserve fund available for such charges or through a line of credit offered by the acquirer.

In short, the issuer (customer-facing bank) and the acquirer (business-facing bank) stand on opposite sides of a transaction but work together to make sure a purchase or return is processed successfully.

Chase, Bank of America and Capital One are three of the five largest card issuers in the US.

Top 5 credit card issuers by market share are Chase, American Express, Citi, Capital One, and Bank of America

Who is the largest merchant acquirer in Canada?

Moneris. Moneris is a payment processing company headquartered in Toronto. It is the largest payment processor in Canada and is owned by RBC and BMO.

An EMV (Europay, MasterCard, and Visa) transaction process involves several steps, starting from the moment a card is inserted into the terminal to the completion of the transaction. Here is a detailed description of each step:

1. Card Insertion

• Cardholder Action: The cardholder inserts the EMV chip card into the payment terminal's chip reader.

• Terminal Action: The terminal detects the presence of the card and establishes a connection with the chip.

2. Application Selection

• Terminal Action: The terminal reads the Application Identifiers (AIDs) from the card.

• Cardholder Action: If multiple applications are available (e.g., credit and debit), the terminal might prompt the cardholder to choose one.

3. Initiate Application Processing

• Terminal Action: The terminal sends a command to the card to initiate application processing. The card responds with its application information and public key certificate.

4. Read Application Data

• Terminal Action: The terminal reads essential data from the card, such as the Primary Account Number (PAN), expiration date, and cardholder name. This step involves reading the necessary data objects from the card.

(Data objects are Basic Encoding Rules-Tag Length Value (BER-TLV) coded, as defined in –

 ISO/IEC 8825 - ISO/IEC 8825-1:2015 specifies a set of basic encoding rules that may be used to derive the specification of a transfer syntax for values of types defined using the specified notation

The Basic Encoding Rules (BER) are a set of Abstract Syntax Notation One encoding rules that define a specific way in which information may be encoded in a binary form.

A "tag-length-value" (TLV) construction is a byte array that has  – 

A tag indicating what the data is

·         The Tag field consists of one or more consecutive bytes. It indicates a class, a type, and a number. EMV tags are coded on one or two bytes.

A length specifying its length (in bytes/octets)

·         The Length field consists of one or more consecutive bytes that indicate the length of the following value field.

o If bit 8 of the most significant byte of the length field is set to 0, the length field consists of only one byte. Bits 7 to 1 code the number of bytes of the value field, for lengths from 1 to 127.

o If bit 8 of the most significant byte of the length field is set to 1, the subsequent bits 7 to 1 code the number of subsequent bytes in the length field. The subsequent bytes code an integer representing the number of bytes in the value field. Two bytes are necessary to express lengths from 128 to 255.

The value itself.

·         The Value field indicates the value of the data object. If L = 00, the value field is not present.

5. Offline Data Authentication (if applicable)

• Terminal Action: The terminal performs Offline Data Authentication (ODA) to verify the authenticity of the card.

• There are three methods for this:

• Static Data Authentication (SDA): The terminal checks the static signature of the card data.

• Dynamic Data Authentication (DDA): The terminal verifies a dynamic signature generated by the card.

• Combined Data Authentication (CDA): Combines both SDA and DDA for enhanced security.

6. Processing Restrictions

• Terminal Action: The terminal checks for any restrictions on the card usage (e.g., expired card, country restrictions).

7. Cardholder Verification

• Terminal Action: The terminal determines the Cardholder Verification Method (CVM) to use (e.g., PIN, signature, or no CVM required).

• Cardholder Action: The cardholder may need to enter a PIN or provide a signature.

• 
  

 TDES - TRIPLE DATA ENCRYPTION SECURE

Table below details about the verification process:

Online PIN

Offline Plaintext

Offline Enciphered

Signature

No CVM

CD CVM

8. Terminal Risk Management

• Terminal Action: The terminal performs risk management checks to decide whether to proceed with the transaction online or offline. This includes:

• Velocity checks: Frequency of card usage.

• Floor limits: Threshold above which transactions must go online.

9. Transaction Authorization Request

·         Terminal Action: If the transaction needs to be processed online, the terminal prepares an Authorization Request (Process the transaction online by requesting an Application Request Cryptogram-ARQC. Pre-authorization requests are always performed online) message, including transaction details and card data and sends it to the acquirer.

10. Online Authorization

• Acquirer Action: The acquirer GP forwards the Authorization Request to the card issuer RBC  or its processor.

• Issuer RBC Action: The issuer evaluates the request, checking for sufficient funds, fraud patterns, and other criteria. The issuer sends an Authorization Response back to the acquirer.

11. Authorization Response

• Acquirer GP Action: The acquirer forwards the Authorization Response to the terminal.

• Terminal Ingenico,Square, Clover Action: The terminal receives the response, which includes the authorization code and status (approved, declined, or referred).

12. Transaction Certificate Generation (if applicable)

• Terminal Action: The terminal may request the card to generate a Transaction Certificate (TC) to confirm the transaction's completion.

• Card Action: The card generates the TC and sends it to the terminal.

13. Receipt Printing

• Terminal Action: The terminal prints a receipt for the cardholder.

• Cardholder Action: The cardholder may need to sign the receipt if required by the CVM.

14. Card Removal

• Cardholder Action: The cardholder removes the card from the terminal.

• Terminal Action: The terminal may display a message confirming that the transaction is complete and that the card can be removed.

15. Settlement

• Acquirer GP Action: The acquirer processes the transaction batch (which includes multiple transactions) for settlement, usually at the end of the business day, and transfers the funds to the merchant's account.

By following these steps, the EMV transaction ensures secure and reliable processing, leveraging the cryptographic capabilities of the chip card to prevent fraud and authenticate the cardholder.

Contactless Payments: 

The growth, how it’s evolved – THe UK has been relying on contactless payments for a long time, and in Australia it has been tap-and-go everywhere, taping their phones and cards.

EMVCo's role is to provide EMV Contactless Payment specifications. What consumers don’t realize is that because they are using the specifications, in more simplistic layman's terms, a one-time security code is being generated to help protect against fraud.

What is a Kernel?

The main objective of an EMV Kernel is to act as a gatekeeper for the card payment transaction and what is going to do is validate the integrity of the card and cardholder data (Terminal risk management) and enable the merchant to only accept transactions that are suitably authenticated. To do that, the Kernel must retrieve reliable information to form risk management judgement on approving or rejecting a payment. The Kernel is software that runs on a piece of hardware that merchants can have and enables payment acceptance – these are usually the point-of-sale ATMs you use to process transactions. A contactless Kernel will provide functions to help the merchant's use cases in transit and tap to mobile devices.

EMVCo - Involved in secure platforms and secure environments but there is heavy focus on functional operability and reliability of transactions. EMVCo plays a crucial role in the global payment industry, particularly in the standardization and interoperability of payment card transactions. Its primary responsibilities and contributions to transaction processing include:

1. Developing Standards: EMVCo creates and maintains the EMV® specifications, which are technical standards for smart payment cards and acceptance devices (such as point-of-sale terminals and ATMs). These standards ensure that cards and devices from different manufacturers and issuers can work together seamlessly.

2. Ensuring Interoperability: By establishing common standards, EMVCo ensures that payment cards can be used globally, regardless of the issuing bank or the country of transaction. This interoperability is crucial for both consumers and merchants, as it facilitates consistent and reliable payment experiences.

3. Security Enhancements: EMVCo's standards focus on enhancing the security of payment transactions. EMV chip technology significantly reduces the risk of fraud compared to traditional magnetic stripe cards by using dynamic authentication data, which makes it difficult for counterfeiters to replicate cards.

4. Certifications and Testing: EMVCo provides certification processes for card manufacturers, terminal manufacturers, and other stakeholders to ensure that their products meet the EMV specifications. This certification process includes rigorous testing to verify compliance with security and functionality requirements.

5. Specification Evolution: EMVCo continuously updates and evolves its specifications to keep pace with technological advancements and emerging threats. This includes incorporating new technologies such as contactless payments, mobile payments, and tokenization.

6. Global Collaboration: EMVCo is a consortium owned by major global payment networks (American Express, Discover, JCB, Mastercard, UnionPay, and Visa). It collaborates with these organizations, as well as other industry stakeholders, to address common challenges and promote the adoption of EMV standards worldwide.

7. Education and Advocacy: EMVCo provides resources, guidelines, and educational materials to help stakeholders understand and implement EMV standards. This includes documentation, best practices, and support for migration to EMV technology.

By fulfilling these roles, EMVCo ensures that the global payment ecosystem remains secure, interoperable, and capable of supporting innovative payment methods, thus fostering trust and reliability in electronic transactions.

PCI SSC – Focus Protecting card data when it is at risk, appropriate controls are in place for protecting card data (Payment Card Industry Security Standards Counci)

The Payment Card Industry Security Standards Council (PCI SSC) plays a critical role in ensuring transaction processing security. Its primary responsibilities and contributions to transaction processing include:

1. Developing Security Standards: The PCI SSC develops and maintains security standards for the payment card industry. These standards include:

   - PCI Data Security Standard (PCI DSS): Sets requirements for protecting cardholder data during and after a transaction.

   - Payment Application Data Security Standard (PA-DSS): Provides guidelines for software developers to ensure their applications securely process payments.

   - PIN Transaction Security (PTS) Requirements: Focuses on the security of devices used to process PIN-based transactions.

2. Ensuring Compliance: PCI SSC establishes and enforces compliance programs to ensure that merchants, service providers, and financial institutions adhere to the security standards. Compliance helps reduce the risk of data breaches and fraud.

3. Certification and Validation: The Council provides certification processes for various stakeholders:

   - Qualified Security Assessors (QSAs): Individuals and organizations certified to assess compliance with PCI DSS.

   - Approved Scanning Vendors (ASVs): Organizations certified to conduct vulnerability scans to identify potential security weaknesses.

   - Payment Card Industry Professional (PCIP) Program: Certifies individuals in understanding and implementing PCI security standards.

4. Training and Education: PCI SSC offers training programs, workshops, and educational resources to help stakeholders understand and implement the security standards. This includes programs for internal security assessors (ISAs) and PCI professionals.

5. Evolving Standards: The Council continually updates and evolves the security standards to address new security threats and technological advancements. This proactive approach ensures that the standards remain relevant and effective in mitigating emerging risks.

6. Global Collaboration: PCI SSC collaborates with various stakeholders, including payment card networks (e.g., Visa, MasterCard, American Express), merchants, service providers, financial institutions, and security professionals. This collaboration helps in the development and dissemination of best practices for securing payment transactions globally.

7. Security Awareness: The Council promotes security awareness and best practices within the payment card industry. It provides guidelines and tools to help organizations enhance their security posture and protect cardholder data.

8. Incident Response Guidance: PCI SSC offers guidance on how organizations should respond to data breaches and security incidents. This includes steps for containment, investigation, and reporting to minimize damage and prevent future breaches.

By fulfilling these roles, the PCI SSC helps ensure the security and integrity of the global payment ecosystem, protecting cardholder data and fostering trust in electronic transactions.

====================================

EMVCo created a layer of specification that ride on 

ISO 7816 - Integrated Circuit cards

ISO 14443 - Substandard for contactless circuit card 

Structure and a framework that seeds into ISO 8583 - For financial transaction messages

New work on ISO 20022 - EMVCo continues to provide interoperable secure transactions that stay in touch with the changes in the card payment ecosystem.

What is the difference between symmetric and asymmetric cryptography?

Symmetric and asymmetric cryptography are two fundamental cryptographic systems used to secure data. Here are the main differences between them:

Symmetric Cryptography

1.  Key Usage:

o    Single Key: Uses the same key for both encryption and decryption.

o    Shared Secret: Both the sender and receiver must possess the same secret key.

2.  Security:

o    Key Management: Securely sharing and managing the secret key between parties is a significant challenge.

o    Speed: Generally faster and more efficient than asymmetric cryptography.

3.  Common Algorithms:

o    Examples include Advanced Encryption Standard (AES), Data Encryption Standard (DES), and Triple DES (3DES).

4.  Use Cases:

o    Often used for encrypting large amounts of data, such as in file encryption or secure communication channels (e.g., SSL/TLS for symmetric session keys).

5.  Example:

o    Alice and Bob agree on a secret key, which they use to encrypt and decrypt messages. If an attacker intercepts the key, they can decrypt the messages.

Asymmetric Cryptography

1.  Key Usage:

o    Key Pair: Uses a pair of keys—one public key for encryption and one private key for decryption.

o    Public and Private Keys: The public key can be shared openly, while the private key is kept secret.

2.  Security:

o    Key Distribution: Easier to distribute the public key openly without compromising security.

o    Computational Cost: Typically slower and more computationally intensive than symmetric cryptography.

3.  Common Algorithms:

o    Examples include RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography), and DSA (Digital Signature Algorithm).

4.  Use Cases:

o    Commonly used for key exchange (e.g., Diffie-Hellman), digital signatures, and secure email (e.g., PGP/GPG).

5.  Example:

o    Alice wants to send a secure message to Bob. She encrypts the message with Bob’s public key. Only Bob, who has the corresponding private key, can decrypt and read the message. Even if an attacker intercepts the encrypted message, they cannot decrypt it without Bob’s private key.

Comparison

Feature	Symmetric Cryptography	Asymmetric Cryptography
Key Usage	Single key for both encryption and decryption	Key pair (public and private keys)
Key Distribution	Challenging to securely distribute the key	Easier to distribute public keys
Speed	Faster and more efficient	Slower and computationally intensive
Security	Secure key management is critical	Public key can be openly shared
Common Algorithms	AES, DES, 3DES	RSA, ECC, DSA
Use Cases	Encrypting large amounts of data, secure channels	Key exchange, digital signatures, secure email
Example Scenario	Shared secret key between two parties	Encrypt with public key, decrypt with private key

In summary, symmetric cryptography is generally faster and more suitable for encrypting large amounts of data, while asymmetric cryptography provides enhanced security for key exchange and digital signatures, despite being slower. Both types are often used together in various security protocols to leverage the strengths of each.

ISO 8583 messaging and cryptography

ISO 8583 is an international standard for financial transaction card originated interchange messaging. It is used for systems that exchange electronic transactions made by cardholders using payment cards. ISO 8583 specifies a message format and a communication flow so that different systems can exchange these transactions in a consistent manner.

ISO 8583 Messaging

Message Structure

An ISO 8583 message is composed of the following components:

1.  Message Type Indicator (MTI):

o    A four-digit numeric code that defines the high-level function of the message, such as whether it's a request or a response, and the type of transaction (e.g., authorization, financial, reversal).

2.  Bitmap:

o    A series of bits that indicates which data elements are present in the message. There are 128 possible data elements in the standard, with the first 64 bits represented by the primary bitmap and the next 64 by the secondary bitmap (if used).

3.  Data Elements:

o    Fields that contain transaction-specific information. Each data element has a predefined purpose, such as the amount of the transaction, the card number, the terminal ID, etc. Data elements can be fixed or variable in length.

Message Types

The MTI structure is defined as follows:

1.  First Digit: Version of the ISO 8583 Standard

o    0: ISO 8583:1987

o    1: ISO 8583:1993

o    2: ISO 8583:2003

2.  Second Digit: Message Class

o    1: Authorization message

o    2: Financial message

o    3: File actions message

o    4: Reversal and chargeback message

o    5: Reconciliation message

o    6: Administrative message

o    7: Fee collection message

o    8: Network management message

3.  Third Digit: Message Function

o    0: Request

o    1: Request response

o    2: Advice

o    3: Advice response

o    4: Notification

o    5: Notification acknowledgement

o    6: Instruction

o    7: Instruction acknowledgement

4.  Fourth Digit: Message Origin

o    0: Acquirer

o    1: Acquirer repeat

o    2: Issuer

o    3: Issuer repeat

o    4: Other

Example Message Flow

1.  Authorization Request (MTI 0100):

o    Sent by the point of sale (POS) terminal to the acquirer.

o    Contains data elements like the primary account number (PAN), processing code, transaction amount, etc.

2.  Authorization Response (MTI 0110):

o    Sent by the issuer back to the acquirer, then to the POS terminal.

o    Indicates whether the transaction is approved or declined, along with any relevant response codes.

Cryptography in ISO 8583

Cryptography is used in ISO 8583 to secure sensitive information such as cardholder data and to ensure the integrity and authenticity of transactions. Here are some common cryptographic methods used:

1.  Data Encryption:

o    Symmetric Encryption: Algorithms like Triple DES (3DES) or AES are commonly used to encrypt sensitive data, such as the PAN or track data, to protect it during transmission.

2.  Message Authentication:

o    Message Authentication Code (MAC): A MAC is generated using a symmetric key and is appended to the message to ensure data integrity and authenticity. The receiver can verify the MAC to ensure that the message has not been altered.

3.  PIN Encryption:

o    PIN Block: The cardholder's PIN is encrypted using a symmetric key (usually 3DES) before being transmitted to ensure its confidentiality.

4.  Key Management:

o    Key Exchange: Secure methods like the Diffie-Hellman key exchange or RSA are used to exchange symmetric keys securely between parties.

o    Key Derivation: Techniques such as deriving session keys from master keys are used to ensure secure and efficient key management.

5.  Digital Signatures:

o    Asymmetric Cryptography: Digital signatures using RSA or ECC can be used to sign transactions or certificates, ensuring the authenticity and non-repudiation of messages.

Example Use Cases

• Data Element 52: Personal Identification Number (PIN) Data, typically encrypted using a symmetric key.

• Data Element 64: MAC, ensuring the message has not been altered and verifying the authenticity of the sender.

Conclusion

ISO 8583 provides a standardized way to exchange financial transaction data, ensuring interoperability between different systems. Cryptography plays a critical role in securing these transactions, protecting sensitive data, and ensuring the integrity and authenticity of messages. Understanding both the messaging format and the cryptographic techniques used is essential for anyone working with financial transaction systems.