EMV — the ICC specifications for payment systems
1
Report Highlights Given the potential risks involved in the use of smartcards, a smartcard designer will naturally want to build high confidence into the security of the product. One way to achieve this is to aim for certification to the highest ITSEC level: E6. This is not a decision to be taken lightly: E6 is dit~icult and costly. However, sponsors have emerged for the E6 cer- tification of critical smartcard components. At E6 formal methods must be confronted for real - actual formal proo/~ are needed as an integral part of the design process; a formal specification which can be quietly put to one side whilst the real devel- opment continues as normal is not acceptable. Over the last few years, great strides have been made in the under- standing and application of formal methods to a commercial product. Formal methods specialists working with smartcard developers have had to produce a workable approach. Other issues that have been encountered in the use of formal methods are: time/ cost, specialized staff, linkage of formal to semiformal speci- fication. In general, a smartcard evaluation will always be performed in the context of a specific hardware platform and O/S. Effectively, the risks to the smartcard from the environment mean that the hardware can not be excluded from the certification. As for formal methods, new ground has had to be covered in pursuit of the smartcard certification: this time in the area of hardware evalua- tion. An approach to evaluation of hardware under ITSEC is currently being defined at an international level. The hardware evaluation can be performed by a specialist hardware laboratory as an adjunct to the CLEF ITSEC evaluation, however, care must be taken to ensure that any overlaps between hardware and software evaluation are addressed adequately as this is an extremely important area. At E6 there is a requirement for the system testing to provide 100% coverage of the source code. Depending on the size of the system, this can be an onerous requirement. However, for the smartcard, the task can be manageable because the small memories place a limit on the size of programs involved. EMV -The ICC Specifications for Payment Systems, Mike Ward. This article provides an overview of the EMV specifications and their current status. The purpose of the EMV standard is to replace the magnetic stripe on the card by an Integrated Circuit or chip, thereby making it a 'smart- card' with memory and processing capabilities. This added intelligence enables better issuer risk management, including improved off-line and on-line authentication and authorization. Off-line Data Authentication is the process whereby the terminal verifies by means of a digital signature the authenticity of critical card data. This process is known as an 'off-line CAM' (Card Authentication Method). Cardholder verification is performed to ensure that the person pre- senting the ICC is the person to whom the application in the card was issued. The terminal uses the data in the ICC to determine whether one of the issuer-specified cardholder verification methods (CVMs) is to be executed: • Off-line PIN processing • On-line PIN processing • A (paper) signature Terminal risk management is performed by the terminal to protect the acquirer, issuer, and system from fraud. It provides positive issuer authorization for high-value transactions and ensures that transactions initiated from ICCs go on-line periodically to protect against threats that might be undetectable in an off-line environment. If a terminal decides to proceed off-line, it obtains a MAC from the card that can be used as a transaction certificate. If the outcome of the decision is to go on-line, the terminal initiates a challenge and response between the card and its issuer that enables on-line authorization or decline. Static data authentication is performed by the terminal using a digital signature based on pubhc key techniques to confirm the legitimacy of critical ICC-resident static data and to detect unauthorized alteration of data after personalization. In the case of Dynamic Data Authentication, a three-layer public key certification scheme is used where the ICC owns a public key pair.The private key is used for signing the dynamic data, and the ICC's public key is stored on the ICC in the form ofa ICC Public Key Certificate, signed by the issuer. Europay and MasterCard have developed a Public Key Certification Service for their members. It comprises the following main functions: • Generation, maintenance and secure storage of the joint Europay-MasterCard private/public key pairs. • Use of the Europay-MasterCard private keys to certify issuer's public keys, and the distribution of the resulting Issuer Public Key Certificates to the corresponding issuers. • Secure distribution (with respect to integrity) of the Europay-MasterCard public keys to acquirers for subsequent storage in merchant terminals, and to issuers for checking Issuer Public Key Certificates. Mitigating Smartcard Risks, Ken Ayer. Smartcards are being widely deployed for a variety of applications. As with any technology, there are risks as well as benefits associated with them. In order to trust the defences offered, they must be independ- ently evaluated, using an appropriate methodology. This paper outlines the threats and a process for evaluating defences. Many smartcards use some form of cryptography to protect programs and data.These are subject to the usual cryptographic threats, as well as some unique to smartcards.The cardholder has complete control of the card almost all the time. He can take it to a laboratory and subject it to any number of hacking attempts. Predominately, the cards are designed to work off-line, so detection measures that rely on on-line detection may not be reliable. Most conventional smartcards support a single application. However, the newest generation of smartcards has a generally more robust oper- ating system that permits adding or deleting application code after the card is issued. The security requirements for the associated operating systems are more stringent than those for conventional cards, as the capability of adding applications also poses a threat. Particular attention must be paid to the procedures for certifying and loading (or deleting) new applications in the field. Most past and current efforts concerning smartcard security have been built on the requirements established by the vendors of the technolo- gy. Little in the way of standardized reviews, objectives or requirements have been published, let alone received broad acceptance. Users, such as banking, have had to either trust the claims of the vendors, or com- mission costly and time-consuming reviews. At a high level there are the following threats: physical threats to the integrated circuit, logical threats to the smartcard, inadequately defined specifications, instantiation errors, cryptographic failure. But this is just a superficial summary. Depending on how they are specified, these five can be expressed in hundreds of possible threat scenarios. Expecting any organization to be knowledgeable let alone expert in more than just a few is wishful thinking, The 'Common Criteria' is an international effort to reconcile infor- mation technology security requirements, which recently became an international standard Once fully implemented, it will provide a basis B
Transcript of EMV — the ICC specifications for payment systems
Report Highlights
Given the potential risks involved in the use o f smartcards, a smartcard designer will naturally want to build high confidence into the security o f the product. One way to achieve this is to aim for certification to the highest ITSEC level: E6. This is not a decision to be taken lightly: E6 is dit~icult and costly. However, sponsors have emerged for the E6 cer- tification o f critical smartcard components.
At E6 formal methods must be confronted for real - actual formal proo/~ are needed as an integral part o f the design process; a formal specification which can be quietly put to one side whilst the real devel- opment continues as normal is not acceptable.
Over the last few years, great strides have been made in the under- standing and application of formal methods to a commercial product. Formal methods specialists working with smartcard developers have had to produce a workable approach.
Other issues that have been encountered in the use of formal methods are: t ime/ cost, specialized staff, linkage o f formal to semiformal speci- fication.
In general, a smartcard evaluation will always be performed in the context o f a specific hardware platform and O/S. Effectively, the risks to the smartcard from the environment mean that the hardware can not be excluded from the certification.
As for formal methods, new ground has had to be covered in pursuit o f the smartcard certification: this time in the area o f hardware evalua- tion. An approach to evaluation of hardware under ITSEC is currently being defined at an international level.
The hardware evaluation can be performed by a specialist hardware laboratory as an adjunct to the CLEF ITSEC evaluation, however, care must be taken to ensure that any overlaps between hardware and software evaluation are addressed adequately as this is an extremely important area.
At E6 there is a requirement for the system testing to provide 100% coverage o f the source code. Depending on the size of the system, this can be an onerous requirement. However, for the smartcard, the task can be manageable because the small memories place a limit on the size o f programs involved.
EMV -The ICC Specifications for Payment Systems, Mike Ward.
This article provides an overview of the EMV specifications and their current status.
The purpose o f the EMV standard is to replace the magnetic stripe on the card by an Integrated Circuit or chip, thereby making it a 'smart- card' with memory and processing capabilities. This added intelligence enables better issuer risk management, including improved off-line and on-line authentication and authorization.
Off-line Data Authentication is the process whereby the terminal verifies by means o f a digital signature the authenticity of critical card data. This process is known as an 'off-line CAM' (Card Authentication Method).
Cardholder verification is performed to ensure that the person pre- senting the ICC is the person to w h o m the application in the card was issued. The terminal uses the data in the ICC to determine whether one of the issuer-specified cardholder verification methods (CVMs) is to be executed:
• Off-line PIN processing
• On-l ine PIN processing
• A (paper) signature
Terminal risk management is performed by the terminal to protect the acquirer, issuer, and system from fraud. It provides positive issuer authorization for high-value transactions and ensures that transactions initiated from ICCs go on-line periodically to protect against threats that might be undetectable in an off-line environment.
If a terminal decides to proceed off-line, it obtains a MAC from the card that can be used as a transaction certificate. If the outcome of the decision is to go on-line, the terminal initiates a challenge and response between the card and its issuer that enables on-line authorization or decline.
Static data authentication is performed by the terminal using a digital signature based on pubhc key techniques to confirm the legitimacy of critical ICC-resident static data and to detect unauthorized alteration o f data after personalization.
In the case of Dynamic Data Authentication, a three-layer public key certification scheme is used where the ICC owns a public key pair.The private key is used for signing the dynamic data, and the ICC's public key is stored on the ICC in the form o fa ICC Public Key Certificate, signed by the issuer.
Europay and MasterCard have developed a Public Key Certification Service for their members. It comprises the following main functions:
• Generation, maintenance and secure storage o f the joint Europay-MasterCard private/public key pairs.
• Use o f the Europay-MasterCard private keys to certify issuer's public keys, and the distribution o f the resulting Issuer Public Key Certificates to the corresponding issuers.
• Secure distribution (with respect to integrity) o f the Europay-MasterCard public keys to acquirers for subsequent storage in merchant terminals, and to issuers for checking Issuer Public Key Certificates.
Mitigating Smartcard Risks, Ken Ayer.
Smartcards are being widely deployed for a variety of applications. As with any technology, there are risks as well as benefits associated with them. In order to trust the defences offered, they must be independ- ently evaluated, using an appropriate methodology. This paper outlines the threats and a process for evaluating defences.
Many smartcards use some form of cryptography to protect programs and data.These are subject to the usual cryptographic threats, as well as some unique to smartcards.The cardholder has complete control o f the card almost all the time. He can take it to a laboratory and subject it to any number o f hacking attempts. Predominately, the cards are designed to work off-line, so detection measures that rely on on-line detection may not be reliable.
Most conventional smartcards support a single application. However, the newest generation o f smartcards has a generally more robust oper- ating system that permits adding or deleting application code after the card is issued. The security requirements for the associated operating systems are more stringent than those for conventional cards, as the capability o f adding applications also poses a threat. Particular attention must be paid to the procedures for certifying and loading (or deleting) new applications in the field.
Most past and current efforts concerning smartcard security have been built on the requirements established by the vendors o f the technolo- gy. Little in the way of standardized reviews, objectives or requirements have been published, let alone received broad acceptance. Users, such as banking, have had to either trust the claims of the vendors, or com- mission costly and t ime-consuming reviews.
At a high level there are the following threats: physical threats to the integrated circuit, logical threats to the smartcard, inadequately defined specifications, instantiation errors, cryptographic failure. But this is just a superficial summary. Depending on how they are specified, these five can be expressed in hundreds of possible threat scenarios. Expecting any organization to be knowledgeable let alone expert in more than just a few is wishful thinking,
The 'Common Criteria' is an international effort to reconcile infor- mation technology security requirements, which recently became an international standard Once fully implemented, it will provide a basis
B
