Emv Explained in few words
1 like2,141 views
The document discusses EMV, a global standard for chip-based credit and debit card transactions. EMV aims to combat fraud by making transactions more secure compared to magnetic stripe-based transactions. An EMV transaction involves communication between the chip card and terminal throughout the transaction to jointly determine if it should be approved, declined, or require online authorization. This added security comes from the chip card containing secret data and dynamically generating unique transaction certificates.
Emv Explained in few words
- 1. Hypercom®, Europe. Pitreavie Drive Pitreavie Business Park Dunfermline Fife, Scotland KY11 8PU Tel. +44 (0) 1383 629800 Fax: +44 (0) 1383 629801 What is EMV ? Ian Smith
- 2. Introduction What is EMV? EMV is a standard designed by Europay, Mastercard and Visa which lays down the rules by which smart cards can be used to perform financial transactions. What is a Smart Card ? For the purposes of this document, a smart card is a card containing a chip, which is compliant with ISO standard 7816. The chip contains both memory and a processor, and is capable of storing data, performing calculations and making decisions. What is the purpose of EMV ? The principal purpose of EMV is to combat fraud associated with mag stripe based transactions, with the ultimate objective being secure offline transactions. EMV is also a global standard ensuring that a card issued anywhere, will work in a terminal anywhere. What is a secure transaction? A transaction is considered secure when it contains sufficient protection to ensure that a person monitoring terminal and/or card activity would be unable to acquire sufficient data to replicate or falsify a subsequent transaction. The major challenge of EMV is to perform a secure transaction in a terminal which may not itself a secure device, i.e. does not contain any secret data or functionality.
- 3. What does an EMV Card look like?. An EMV card looks like a normal mag stripe card with the addition of a set of gold contacts on the front surface. Front View Rear View What are the contacts for ?. There are 8 contacts on the card but only 5 are currently used and these allow the EMV chip and terminal to be connected together. The contact functions are 5V, 0V, Clock, Data and Reset. What’s on the mag stripe ?. The mag stripe contains the same data that is present on existing cards. Eventually, the mag stripe will be phased out, but when this is to happen has not yet been agreed. Can I swipe an EMV card Yes and No, in addition to the usual data, the mag stripe of an EMV card also contains a service code which indicates to the terminal that a chip is also present. Chip capable terminals will not accept the swipe and will insist that the chip is inserted instead. Non chip capable terminals will accept the mag swipe. Why does an EMV transaction take longer than mag stripe ? An EMV transaction is permitted to take up to 5 seconds longer than the equivalent mag stripe transaction. The reason for this is that the two transaction types are very different. An EMV transaction involves considerably more processing, which is described in the remainder of this document
- 4. What’s the difference between a mag stripe and EMV transaction ? A Mag Stripe Transaction In a mag stripe transaction, the card is swiped and a brief burst of data flows from card to terminal. Having received the data, the terminal makes a decision to accept the transaction, reject the transaction or go online for authorisation. Terminal Authorisation Host Terminal alone makes Accept / Decline / Online Decision Brief flow of data Card to Terminal only Authorisation communications Swipe This transaction presents a number of security problems. 1. The data on the card is writeable and may have been modified 2. The card may even be a copy of another card. 3. The card does not “know” if the authorisation host is “real” 4. The host does now “know” if the card is “real”. 5. The card does not have to be present as manual keying is possible 6. A card holder can deny that a transaction ever took place.
- 5. A chip transaction When a chip card is inserted into a terminal, a conversation between card and terminal takes place throughout the transaction. The terminal and card jointly make a decision to accept the transaction, reject the transaction or go online. Terminal Authorisation Host Terminal and card make joint Accept / Decline / Online Decision Continuous flow of data in both directions Authorisation communications Insert Secret Data This transaction presents a number of security improvements. 1. The chip data is read only and cannot be modified. 2. It is impossible to make a complete copy of a chip as each contains secret data which is not accessible to the outside world. 3. If data is copied to another card and modified there, this is easily detected and impossible to conceal. 4. For online transactions, the card verifies that the host it is real. 5. For online transactions, the host verifies that the card is is real. 6. For each transaction, an encrypted certificate is created which proves that the card was present and that the transaction actually took place. 7. PIN verification can be used for offline and online transactions
- 6. The principal differences between mag stripe and chip cards are; • The chip is an active participant in a transaction and contributes to the accept/decline/online decision. In fact, the chip has the final say and can reject or force online a transaction, against the wishes of the terminal. • A chip transaction uses secret data, which is buried on the card and is never revealed to the terminal. • As the chip and terminal communicate throughout a transaction, the chip card must remain in the terminal throughout, This usually prevents the signature on the card from being viewed therefore signature comparison cannot be performed until the transaction is over. If the signature is then found to be unsatisfactory, the transaction must be voided. • A chip card can contain multiple functionality, i.e. Credit/Debit and Purse. Each type of functionality contained on a card is known as an application. What is the extra chip/terminal communications for ?. Part of the data, which flows from chip to terminal, is the same as that which would previously have been read from mag stripe. However, this is a small part of the overall data flow, and the majority is associated with additional security, and the handling of multiple card applications. The remainder of this document will describe the sequence of steps which form an EMV transaction, concentrating on the data involved including where it comes from and what happens if it goes wrong.
- 7. EMV Transaction Flow Summary The steps involved in an EMV transaction are; 1. The user inserts a card into the terminal. 2. The terminal powers up the card. 3. The terminal looks on the card for an application which it knows how to run. (If more than 1 is found, the user is given the choice). 4. All of the data from the chosen application is read from the card into the terminal. 5. The terminal verifies that the card data has not been modified since the card was manufactured. 6. The user is then prompted to enter a transaction amount. 7. If supported the user is prompted to enter their PIN 8. The terminal and card make a joint decision to reject, authorise offline or go online for authorisation. 8.1 Reject The card is powered down 8.2 Authorise Offline Card generates a unique encrypted certificate proving that on a given date and time, a transaction for a particular amount was performed by a particular terminal. The card is then powered down 8.3 Authorise Online Via the terminal, the card and host prove to each other that they are real. If this process is successful, a certificate similar to that described above is generated by the terminal. At this time, the authorisation host, via the terminal may optionally transmit one or more issuer scripts to the card. The card is then powered down Each of the above steps will now be covered in more detail.
- 8. Card Insertion When a chip card is inserted into a terminal, the EMV standard requires that the chip is handled with care. To operate, the chip requires DC power a clock pulse train and a reset signal, but these must be supplied in the correct timed sequence. When this is done, the card will respond by powering up and transmitting a reply, containing the card’s communications capabilities, back to the terminal. This process is called Answer to Reset (ATR) and allows the terminal to configure itself to match the capabilities of the card. This process is typical of all EMV commands in that the card will only transmit data in response to a command from the terminal and will never ‘speak out of turn’. When a card is inserted into the terminal, it is possible that the initialisation process may fail because; 1. The card does not have a chip. 2. The card may have been inserted the wrong way round. 3. The chip may be ‘dead’ 4. The terminal’s card coupler may be inoperative. If any of the above happen, the user is invited to try again. If a second failure occurs, the user is invited to perform a mag swipe instead. Card Removal. The user can remove a chip card from a terminal at any time. If this should occur in mid transaction, the EMV standard requires that the chip be shut down in a controlled manner. This is to ensure that the chip is not left ‘hanging’ and will operate correctly when next used. To do this, the card coupler is equipped with a sensor, which provides advance warning of card removal. The terminal immediately responds to this warning by performing the chip deactivation sequence before electrical contact with the chip is lost. The transaction is then voided. At the end of a normal transaction, the chip is also deactivated in a controlled sequence.
- 9. Determine Supported Applications Once a chip has been powered up, the next step is to determine which applications are on board. An application is a discrete type of activity, which the card ‘knows’ how to perform. Typical applications are; Credit/Debit Loyalty Club Membership Passport Medical History A terminal cannot assume that a card, which has been inserted, contains an EMV compliant chip and must be able to handle anything, which the user cares to insert, within reason. The terminal must therefore establish which applications are present on the card and this is done using a number, contained in each application, called the Application Identifier (AID). Each AID is made up of two parts, the first 5 bytes are called the registered identifier (RID) and identify the organisation which created the application. Typical RIDs are; A000000003 Visa A000000004 Mastercard A000000025 American Express The second (optional) part of an AID is called the PIX . It can be up to 11 bytes long and is used to differentiate between the applications created by each issuer. Typical AIDs (including PIX) are; A0000000031010 Visa Credit/Debit A0000000031020 Visa Delta A0000000041010 Mastercard Credit/Debit
- 10. When a card is inserted, the terminal must read from it the supported AIDs. This list is then compared with the AIDs with which the terminal has been configured. Terminal Terminal creates list of mutually supported AIDs Config Host sends AIDs list to terminal Terminal reads AIDs from card Config Host Card AIDs A001 A002 A003 AIDs A001 A002 A003 AIDs A001 A002 A004 When comparing AIDs, the terminal must use two different matching criteria. The simplest of these is exact matching and this requires the AID in the terminal and card must match exactly. The second criterion requires that all of the characters in the terminal AID must match those of the card but that the card AID may have additional unmatched characters.
- 11. This is called partial matching, for example; AID A00000002501 in the terminal is a partial match for AIDA0000000250199 in the card. Using the above rules, the AIDs supported by terminal and card are compared and a list of mutually supported applications derived. There are three possible outcomes from this process; • No mutually supported AIDs exist. The card is powered down and the card rejected. At present, the user is then invited to perform a mag swipe, but this may change. • One mutually supported AID exists If the application requires user confirmation, this is requested otherwise the application is run immediately. • Multiple mutually supported AIDs exist. The list of AIDs is offered to the user. The chosen application is then run. Note; The AIDs supported by a terminal are configured using TermMaster and it is important that they are entered correctly. If they are entered incorrectly, valid cards will be rejected by the terminal.
- 12. Application Selection Once the user has chosen an application, the next step is for the terminal to request that it be run by the card. This is done by transmitting the appropriate AID, to the card, as part of a select command. The card will normally respond by transmitting introductory data about itself back to the terminal. If this happens, all is well and the transaction can proceed. However, the application selection process can fail because; 1. The application advises that it is blocked. The card issuer does this to prevent the application being used, usually because the cardholder has not paid their bill. 2. The application’s conditions of use have not been satisfied. Application is for ATM use only Application cannot be used in foreign countries. Application cannot perform this type of transaction. (and many others) If all is well, the terminal uses the data list provided by the card, to read all of the data necessary to perform a transaction. Terminal 2) Terminal reads all data from card Card 1) Terminal sends select command to card 3) Terminal stores data in a database for later use One all of the data has been read, the next step is to confirm that the data on the card has not been modified, which is done using a process called data authentication.
- 13. Data Authentication EMV allows for two forms of data authentication, Static Data Authentication (SDA) and Dynamic Data Authentication (DDA). 1. Static Data Authentication This is a checking process which allows the terminal to confirm that the data read from the card has not been modified since the card was manufactured. Unfortunately this process cannot detect a card which is an exact duplicate of another card. 2. Dynamic Data Authentication This is a checking process which process can detect both modified and duplicate cards. To do this, in addition to the checks performed previously, the terminal and card must perform cryptography using secret data on the card. This requires that the card contains a powerful processor and at present, no real cards in circulation can perform DDA. Test cards however do exist. As data authentication failure is one of the most common reasons for transaction failure, the process will be described in more detail, but before doing so it is necessary to briefly go over the cryptography involved. Cryptography EMV employs two forms of cryptography, DES and RSA, each of which have different properties and are used for different purposes.
- 14. DES DES stands for Data Encryption Standard, and is a very traditional style of code. It is used to convert a message from a readable form into one which cannot be read. To encrypt a message under DES, the message is fed into a DES encryption engine and a key is supplied. The engine scrambles the plain text using the key and outputs an encrypted version. To decrypt a DES message, the encrypted text is fed into a DES decryption engine along with the original key. Encrypted Text DES Decryption Plain Text DES Key It is vital that the same key is used to both encrypt and decrypt the message. It is also vital that the key remains secret or security is lost. DES EncryptionPlain Text Encrypted Text DES KEY
- 15. RSA DES is extremely powerful, but codes of this type have existed for hundreds of years. RSA on the other hand is a new type of code named after it’s authors, Rivest, Shamir and Adleman, who invented it in 1978. Instead of being used to protect a message from ‘prying eyes’, RSA is used to prove the authenticity of a message i.e. that the message genuinely originates from the person or organisation who claims to have sent it. RSA uses not one key but two, known as a key pair. The following explanation assumes that a pair of keys (A and B) has been created. To encrypt a message under RSA, it is necessary to feed the plain text into an RSA encryption engine along with Key A. R S A E n c r y p t T e x t e n c r y p t e d u n d e r K e y A P la in T e x t R S A K e y A To decrypt such a message, it is necessary to use the other key. RSA Decrypt Plain TextText encrypted under Key A RSA Key B This also works the other way round, i.e. a message encrypted under key B must be decrypted using key A. If decryption is attempted using the original key, the result is gibberish.
- 16. When RSA is used, it is normal that one of the keys is kept secret and the other openly published, with these being known as the private and public keys respectively. Publishing a key might at first seem odd, but the reason is as follows. An organisation can send messages encrypted under a private key to any body who has knowledge of the corresponding public key. Anyone in receipt of such an encrypted message can prove it’s authenticity by attempting to perform decryption using the known public key. If the message can be successfully decrypted, this proves that the sender encrypted using the corresponding private key and therefore that the message is genuine. Correspondingly, although knowledge of the public key allows the authenticity of a message to be established, it does not confer the ability to create false messages. Encrypting a message under the public key will not succeed as others will be unable to decrypt it.1 Is is vital that the private key remain secret or security is lost. It is also vital that public keys are obtained from a trusted source. For example, if you expect to receive messages from organisation X, you will need a copy of their public key. A fraudster may generate their own key pair and persuade you that the public key actually belongs to organisation X. If you accept this key, then the fraudster can then send you messages, which you will believe to originate from organisation X. 1 Ironically, were a message to be encrypted under the public key, the only person who could read it would be the legitimate owner of the corresponding private key.
- 17. Data Authentication (Once Again) RSA is used in Data Authentication as follows. When a card is manufactured, the issuer takes some of the important data (PAN cardholder name etc) and encrypts it under RSA using a private key. The original and encrypted data are then stored on the card. RSA Encrypt Private Key Original and encrypted data stored on card Original Data During a transaction, the terminal reads the original and encrypted data from the card. Original and encrypyed data read from card Original Data RSA Decryption Terminal compares original and decrypted data RSA Public Key Using the corresponding public key, the terminal decrypts the card data. If the decryption does not work, the card is suspect. If the decryption works, but the encrypted data does not match the original, then the card has been modified since manufacture.
- 18. This allows fake and modified cards to be detected but a card containing an exact copy of the data from another would pass this test. Therefore SDA authentication cannot be considered to be completely secure. This final problem can be addressed by using Dynamic Data Authentication (DDA). Dynamic Data Authentication In SDA transactions, the card contains data, which was encrypted using the issuer’s private key, whilst in DDA transactions, the card actually contains the issuer’s private key and can perform RSA encryption. When DDA is performed, the terminal first performs SDA as described previously before going on to do the following additional step. The terminal generates a random number, which along with other transaction related data is transmitted to the card. The card then RSA encrypts the data using it’s private key, and returns the result to the terminal. Terminal Card 1) Terminal sends message to the card including date, amount, and a random number RSA Private Key 2) Card encrypts data then returns it to terminal RSA Public Key 3) Terminal decrypts data and compares it with original message. If they match, all is well The terminal then attempts to decrypt the data using the corresponding public key. If it can recover the original data (including the random number) this proves that the card ‘knows’ the private key. Since the private key is hidden, and cannot be copied, the card must be genuine.
- 19. As further security measure, the EMV public key system also includes the concept of date expiry. The encrypted data contained on a card has an expiry date after which the terminal decryption process is mandated to fail. Data authentication can fail for the following reasons. • The terminal does not contain the required public key • The public key contained in the terminal is incorrect. • The encrypted data certificate on the card has expired. • The terminal date is set incorrectly and the terminal thinks that the encrypted data certificate on the card has expired. Hypercom terminals can store 60 RSA public keys which are loaded into the terminal via TermMaster. To prevent fraud, when adding a new key, to TermMaster, it is vital that that the authenticity of each key is confirmed. Once the authenticity of the card data has been confirmed, the transaction can move on to cardholder verification.
- 20. Cardholder Verification This is the process by which it is determined that the person presenting the card is the legitimate user. To do this the card presents to the terminal, a list of methods by which this may be done. Associated with each method is a rule which determines what should happen if the method is unsuccessful. The available methods are: • Signature • Offline Plain Text PIN (PIN verified by the card) • Offline Encrypted PIN (PIN verified by the card) • Online encrypted PIN (PIN verified by authentication host) • No CVM required The available rules are • Apply the next method if this is unsuccessful • Fail cardholder verification if this method is unsuccessful Using this system it is possible to build a CVM list such as: 1. Perform Encrypted PIN (If unsuccessful perform the next method) 2. Perform Plain Text PIN (If unsuccessful perform the next method) 3. Perform Signature (If unsuccessful, fail CV processing) If the cardholder verification process is unsuccessful, the transaction does not terminate immediately as the eventual outcome is determined by the action analysis process.
- 21. Action Analysis After cardholder verification has been performed, action analysis takes place. This is the process by which the terminal and card jointly determine if the transaction should be rejected, accepted offline or online authorisation obtained. It is performed in two stages. • The first part of the process is performed by the terminal which uses it’s own built in rules to determine what it thinks should be done. • The terminal’s recommendation is then transmitted to the card which goes on to make the final decision. • Once the final decision is made, for each transaction, the card generates a unique certificate called an application cryptogram which contains details of the transaction including date, amount, terminal and card information. This data is encrypted by the card and can be used to prove that a particular terminal performed a transaction, with a particular card, for a certain amount, at a certain date and time. When making the initial decision, the terminal makes use of data items called Transaction Verification Result (TVR) and Action Codes. Transaction Verification Result The TVR is a 5 byte number, maintained by the terminal, in which each bit represents the status of an event which may or may not have happened during the transaction. e.g Data authentication failed, transaction randomly selected for online processing, cardholder verification failed , offline transaction limit exceeded, floor limit exceeded etc. Action Code An action code is also a 5 byte number, in which the bits have similar meanings to those of the TVR. Whilst the setting of a bit in the TVR indicates that a particular event happened, the setting of the equivalent bit in an action code indicates what the terminal’s response to the event should be.
- 22. When performing this comparison, each bit in the TVR is compared with it’s equivalent in the action code. In the example below, the least significant bit is set in both codes. 0 0 0 0 0 1 0 1 Transaction verification result (TVR) 1 1 1 1 0 0 0 1 Action Code 1) The code is bitwise compared to the transaction result The first part of the action analysis process is performed by the terminal and consists of comparing the terminals TVR result with three action codes called denial, offline and default. Denial The TVR is first compared to the denial code. If any of the corresponding bits are set, the terminal will recommend denial to the card. Online The TVR is then compared to the online action code. If any corresponding bits are set, the terminal will recommend online authorisation to the card. Otherwise it will recommend offline authorisation. Default If a terminal has attempted to go online, but the host cannot be contacted, this code determines if the terminal can authorise the transaction offline.
- 23. The bit settings of the action codes are very important and come from two separate sources. The terminal (via Termmaster) is configured with denial online and default codes, which are known as the Terminal Action Codes. In the same way, each card is also configured with denial, online and default codes known as the Issuer Action Codes. The action code used during a transaction is derived by merging the equivalent terminal and issuer codes together. The following example shows how the denial action code is constructed. 0 0 0 0 0 1 0 1 Transaction verification result (TVR) 1 0 1 0 0 0 0 0 0 1 0 1 0 0 0 1 1 1 1 1 0 0 0 1 Terminal Denial Code Card Denial Code Merged Denial Code 1) The terminal and card codes are merged together 2) The merged code is bitwise compared to the transaction result 3) This transaction would be denied Note: The terminal action codes present in a terminal are configured via TermMaster and it is very important that they are entered correctly. As a consequence of the merging process described above it is very difficult to answer the seemingly simple question “Why was my card rejected?
- 24. When the TVR/Action Code comparison process is complete, the Terminal transmits it’s recommendation to the card along with certain transaction related data, usually including the date, amount, PAN and a random number. The card is permitted to agree with, or downgrade, the terminal’s recommendation and the following table lists the possible outcomes. Terminal Recommendation Possible Card Decision Reject Reject Online Online Reject Accept Accept Online Reject In reaching it’s decision, the card is permitted to employ scheme specific rules, such as customer spending patterns, which are unknown to the terminal. In addition to it’s decision, the card also returns a certificate, encrypted under DES (using a key which is part of the secret data). The type of certificate returned will depend if the transaction is to be rejected, accepted or online authorisation requested.
- 25. Offline Approval For an offline approval, the encrypted data, called the Transaction Certificate, is stored in the transaction store. This certificate contains proof that the transaction actually took place. As the certificate is encrypted, alteration or forgery is not possible, therefore the cardholder cannot deny that a transaction took place and the merchant cannot subsequently alter any of the transaction details. 1) Terminal sends message to the card including date, amount, and a random number DES DESKey 2) Card encrypts data then returns it to terminal 3) Terminal stores encrypted certificate in transaction tank Rejected Transactions For a rejected transactions the procedure is very similar to that described above. The encrypted data, called the AAC, which is returned by the card is stored in the transaction store. This certificate contains proof that the transaction actually took place but was rejected. As the certificate is encrypted, alteration or forgery is not possible, therefore the merchant cannot subsequently alter the transaction details to make it appear that a valid transaction took place..
- 26. Online transactions For online transactions, a similar process to that described previously takes place with the exception the certificate returned from the card contains an authorisation request certificate (ARQC). The terminal forwards this to the authorisation host. When the host receives the message, it attempts to replicate the cryptology performed by the card. The response transmitted to the terminal will depend if this is successful. 1) Terminal sends message to the card including date, amount, and a random number DES DESKey 2) Card encrypts data then returns it to terminal 3) Terminal sends original and encrypted data to authorisation host DES DES Key 4) Host attempts to replicate encryption performed by card. 4) Terminal receives response fromhost. (see next drawing)
- 27. If the host cannot replicate the original cryptology, it generates a rejection certificate (ARPC) which is transmitted to the terminal. The certificate is stored and the transaction terminated. 4) Terminal stores rejection certificate DES DES Key 1) Host fails to replicate card encryption. 3) Terminal receives reject response from host. 2) Host encrypts rejection certificate and sends it to terminal 5) Terminal shuts down the card
- 28. If the host is able to replicate the card’s cryptology then it knows that it is dealing with a genuine card. However the host must now prove to the card that it is also genuine, and this is done by performing a further encryption of the original data, which is then sent back to the terminal. 4) Terminal receives response fromcard. (see next drawing) DES DESKey 2) Card tries to replicate host cryptology 3) Terminal sends challenge to card DES DES Key 1) Host replicates card encryption 2) Host encrypts DES card challenge and sends to terminal What happens next depends if the card is able to replicate the cryptology performed by the host.
- 29. If the card is able to replicate the cryptology performed by the host, then it knows that the host is real. The transaction may now be completed and to do this, the card then generates a transaction certificate (TC) which is transmitted to the terminal and stored as before. 3) Terminal receives and stores transaction certificate DES DESKey 2) Card encrypts transaction certificate and sends to terminal 1) Card replicates host cryptology
- 30. If the card is unable to replicate the cryptography performed by the host, then the card will assume that the host is not ‘real’. If this should happen , the transaction must be voided and to do this, the card generates a rejection certificate (AAC) which is transmitted to the terminal. When this certificate is received by the terminal it is stored as previously. There is however an additional step to be performed as the authorisation host must be advised that the transaction did not succeed. To do this, the terminal may create a reversal record or immediately go online for a second time (protocol specific).
- 31. 3) Terminal receives and stores reject certificate fromcard. DES DESKey 1) Card fails to replicate host cryptology 4) Terminal goes online and tranmits certificate to host 2) Card encrypts reject certificate and sends to terminal Host voids transaction
- 32. Issuer Scripts Once the transaction has been completed, EMV has one more trick up it’s sleeve. As part of the authentication message, a host can include one or more issuer scripts scripts. The terminal, which does not understand the script contents, simply forwards them to the card, which executes the instructions contained. Scripts can be used to perform such tasks as blocking applications or updating card data. This scripting operation is ‘invisible’ to the user. Security Summary The security status of the various combinations of data authentication and on/offline authentication is as follows. Authentication/Mode SDA DDA Offline Not fully secure Secure Online Secure Secure PIN Entry Mode Plain Text Encrypted Offline Not fully secure Secure Online -------- Secure From this table it can be seen the offline SDA transactions are not fully secure. It for this reason that offline authorisation is currently restricted to low risk transactions involving low amounts etc. Although full security could be obtained by sending all transactions online, this is unacceptable from both the merchant acquirer and network loading standpoints. For this reason, the objective of fully secure offline transactions will not be realised until cards supporting both DDA and Encrypted offline PIN are in general use.
- 33. Appendix: Additional FAQs What do the terms ‘EMV3’ and ‘EMV3.1.1’ mean There have been several versions of the EMV standard. EMV3 was released in June 1996 and has since been superseded by EMV3.1.1, released in January 1998. A new version of the standard, called EMV4 was released in December 2000. What is type approval ?. Type approval is the testing process by it is proved that a representative terminal complies with the requirements of the EMV standard. Type approval is awarded by an organisation known as EMVCo There are separate EMVCo approval processes for EMV levels 1 and 2. What do the terms ‘Level 1’ and ‘Level 2’ mean ?. EMV level 1 is the part of the EMV specification which deals with the mechanical, electrical and communications interface between card and terminal. For example, it dictates physical card size limits, current consumption and the rules under which card to terminal communications take place. EMV Level 2 is the part of the EMV specification which deals with the functionality required to support financial transactions. Principally this involves application selection, transaction processing and cryptography.